2009-05-19 8 views
6

मैं एक ऐप लिख रहा हूं जो नेटवर्क कनेक्शन पर सुनता है, और जब कुछ डेटा आते हैं, तो यह वापस जवाब देता है, और आने वाले डेटा के आधार पर, इसे वापस जवाब देने से पहले उपयोगकर्ता (संवाद दिखाएं) से पूछने की आवश्यकता हो सकती है।मॉडल-व्यू-व्यूमोडेल आर्किटेक्चर में मॉडल की विधि के बीच से उपयोगकर्ता इनपुट को साफ तरीके से कैसे प्राप्त करें?

मुझे नहीं पता कि एमवी-वीएम आर्किटेक्चर में यह साफ तरीके से कैसे किया जाए: यदि मुझे आने वाले डेटा के आधार पर जीयूआई अपडेट करने की ज़रूरत है तो घटनाओं और बाध्यकारी संग्रहों को अच्छा लगेगा, लेकिन अगर मुझे वास्तव में एक एवर की आवश्यकता है तो क्या होगा वापस जवाब देने से पहले उपयोगकर्ता?

और चीजों को और खराब करने के लिए, मैं इसे सिंक्रनाइज़ करना चाहता हूं, क्योंकि मैं चाहता हूं कि मेरा उत्तर एल्गोरिदम एक ही स्थान पर हो, अस्पष्ट 'कौन-कॉल-कौन' जिम्मेदारियों के साथ कई कॉलबैक में विभाजित न हो।

बस

HandleMessage(Message msg){ 
    string reply; 
    if (msg.type == 1) { 
     reply = ... 
    } else { 
     string question = msg... 
     reply = ShowModalDialog(question); // MVVM violation! 
    } 
    sender.Send(reply); 
} 

लेकिन जैसे कुछ मैं नहीं चाहता कि मॉडल से देखने या viewmodel कॉल करने के लिए, मॉडल के रूप में पुन: प्रयोज्य और परीक्षण योग्य होने की जरूरत है चाहता हूँ - मैं हर परीक्षण समय में संवाद पॉपिंग नहीं करना चाहते, और यह एमवीवीएम का उल्लंघन होगा! कोई घटना नहीं (वे केवल एक तरफ हैं जहां तक ​​मुझे पता है, और घटना मूल के जवाब पाने के लिए कोई पिछड़ा चैनल नहीं है) या डाटाबेसिंग, क्योंकि यह असीमित होगा।

क्या यह करने योग्य है? यह एक प्रश्न है जिसे मैंने कई परीक्षण संचालित विकास प्रचारकों से पूछा, और अब तक, मुझे व्यावहारिक रूप से उपयोग करने योग्य उत्तर नहीं मिला। फिर भी, प्रसंस्करण के बीच में कुछ अतिरिक्त इनपुट की आवश्यकता काफी आम है।

धन्यवाद!

संपादित करें: यह एप्लिकेशन तर्क है, इसलिए यह स्पष्ट रूप से मॉडल से संबंधित है, और यहां तक ​​कि यदि इस मामले में ऐसा नहीं होता है, तो भी मैं मामलों के समाधान को जानना चाहता हूं जब मुझे वास्तव में व्यवसाय के मध्य में उपयोगकर्ता के इनपुट की आवश्यकता होती है मॉडल में तर्क दिनचर्या।

उत्तर

3

यह उन समस्याओं में से एक है जो एमवीवीएम स्वयं पर हल नहीं करता है। एक समाधान उपयोगकर्ता से पूछताछ करने के लिए एक सेवा का उपयोग करना होगा और उसके बाद ViewModel उस सेवा का उपयोग करेगा।

अपने प्रोजेक्ट में हम PRISM जो एक सेवाओं ढांचा प्रदान करने के साथ भी जीयूआई विकास को सरल बनाने की के लिए अन्य उपकरण प्रदान करता है का उपयोग कर रहे हैं।

Here's की एक writeup कैसे सेवाओं प्रिज्म में काम करते हैं।

तो विशेष रूप से आपके मामले में मैं कुछ प्रकार का आईओसी बनाउंगा, इसके साथ एक क्वेरी सेवा पंजीकृत करूंगा, फिर आईओसी में व्यूमोडेल पास में और फिर आईओसी का उपयोग क्वेरी सेवा प्राप्त करने के लिए करें, और उपयोगकर्ता से पूछताछ के लिए इसका उपयोग करें । और काम? ज़रूर।लेकिन इसका मतलब यह है कि आप आईओसी में बस इसे बदलकर परीक्षण के लिए अन्य कार्यान्वयन के साथ क्वेरी सेवा को प्रतिस्थापित कर सकते हैं।

एमवीवीएम + सेवाएं = अल्टीमेट पावर!

+0

+1 इसे करने से मुझे बहुत बेहतर समझाने के लिए +1। –

+0

धन्यवाद, यह एक स्वच्छ समाधान की तरह लगता है, मैं लिंक पढ़ूंगा (उनके लिए धन्यवाद!) –

0

दरअसल, यह सभी एप्लिकेशन तर्क में शामिल नहीं है।

ऐसा लगता है कि आपके पास 2 अलग-अलग "विचार" हैं। प्रारंभिक एक (नेट पर डेटा आ रहा है), और दूसरा एक (पुष्टिकरण संवाद) है।

मॉडल निर्धारित करने के लिए कोई नया दृश्य प्रदर्शित करने के लिए की जरूरत है की जरूरत है, यह प्रदर्शित करने के लिए दृश्य संकेत, फिर बाद में उस दृश्य से इनपुट का जवाब।

इसे एक ही चरण में करने की कोशिश न करें।

+0

मैं पहली टिप्पणी से सहमत हूं - हाँ, प्रारंभिक दृश्य केवल सेवा की कंसोल लॉग विंडो है, और डेटा इनपुट संवाद को एक और दृश्य के रूप में माना जा सकता है। होवर, मॉडल एल्गोरिदम संचालित है, और मुझे यह लगता है कि यूआई द्वारा अतुल्यकालिक रूप से बुलाए गए हिस्सों में एक अलोरिथ्म को विभाजित करना बहुत पागल है - और कुछ मामलों में, यह वास्तव में संभव नहीं है। इसके अलावा, रखरखाव के दृष्टिकोण से, एक मेटोड में एल्गोरिदम होना बेहतर होता है। इसलिए, जीयूआई को कॉल करना सिंक्रोनस होना चाहिए। –

+0

मैं समझता हूं कि आपका क्या मतलब है। मुझे कुछ वास्तव में परेशान स्थानों में राज्य मशीनों का उपयोग करना पड़ा। हालांकि मुझे पता है कि आप वहां जाना नहीं चाहते हैं, आपको एक अच्छा मौका देना होगा। यदि नहीं, तो बढ़िया है, लेकिन आप इसे खत्म करना चाहते हैं - शायद यह है कि आप क्या कर रहे हैं। एक संवाद बॉक्स अक्सर धागे को जारी करने का तात्पर्य है। मैं आपके बिंदु से असहमत नहीं हूं कि यह पागल है :) –

1

अगर इस विचार MVVM के सिद्धांतों के साथ सख्त रखने में है मैं नहीं जानता, लेकिन ... मैं एक सेवा (एक अंतरफलक के माध्यम से संदर्भित) के रूप में संवाद कार्यक्षमता को संपुटित होगा। सेवा का कार्यान्वयन यूआई परत में होगा, लेकिन परीक्षण उद्देश्यों के लिए आप इंटरफ़ेस को "नकल" करेंगे।

संबंधित मुद्दे