2010-04-05 11 views
17

मैं उल्लिखित एमवीवीएम पैटर्न के साथ प्रयोग कर रहा हूं और मुझे कुछ मामलों में स्पष्ट सीमाओं को परिभाषित करने में कठिनाई हो रही है। मेरे आवेदन में, मेरे पास एक संवाद है जो मुझे नियंत्रक के लिए कनेक्शन बनाने की अनुमति देता है। संवाद के लिए एक व्यूमोडेल क्लास है, जो काफी सरल है। हालांकि, संवाद एक अतिरिक्त नियंत्रण भी होस्ट करता है (ContentTemplateSelector द्वारा चुना गया), जो कि कनेक्ट होने वाले विशेष प्रकार के नियंत्रक के आधार पर भिन्न होता है। इस नियंत्रण में अपना खुद का व्यूमोडल है।एमवीवीएम: नेस्टेड व्यू मॉडल्स के बीच बातचीत को कैसे संभाला जाए?

मुझे जो समस्या आ रही है वह यह है कि, जब मैं ठीक दबाकर संवाद बंद करता हूं, तो मुझे वास्तव में अनुरोधित कनेक्शन बनाना होगा, जिसके लिए आंतरिक नियंत्रक-विशिष्ट व्यूमोडेल क्लास में जानकारी प्राप्त की आवश्यकता होती है। यह केवल कंट्रोलर-विशिष्ट व्यू मॉडेल क्लास को एक सामान्य इंटरफ़ेस लागू करने के लिए मोहक है जो कनेक्शन बनाता है, लेकिन आंतरिक व्यूमोडेल वास्तव में इस निर्माण का प्रभारी होना चाहिए?

मेरा सामान्य प्रश्न यह है कि: क्या आम तौर पर स्वीकार्य डिज़ाइन पैटर्न हैं कि व्यूमोडल्स को एक-दूसरे के साथ कैसे बातचीत करनी चाहिए, खासकर जब 'माता-पिता' वीएम को 'बच्चे' वीएम से मदद की आवश्यकता होती है ताकि पता चल सके कि क्या करना है?


संपादित करें:

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

मैं कुछ इस तरह के साथ समापन (सरल बनाने):

public interface IController 
{ 
    IControllerConnectionBuilder CreateConnectionBuilder(); 
} 

public interface IControllerConnectionBuilder 
{ 
    ControllerConnection BuildConnection(); 
} 

मैं अपने भीतर की ViewModel वर्ग IControllerConnectionBuilder को लागू किया है और नियंत्रक भीतरी ViewModel देता है। शीर्ष-स्तरीय व्यूमोडेल फिर IControllerConnectionBuilder (छद्म-जादुई तंत्र के माध्यम से) को विज़ुअलाइज़ करता है। यह अभी भी मुझे थोड़ा परेशान करता है कि यह मेरा आंतरिक व्यू मॉडेल इमारत का प्रदर्शन कर रहा है, लेकिन कम से कम अब मेरे शीर्ष-स्तरीय व्यू मॉडेल को गंदे विवरणों के बारे में पता नहीं है (यह भी पता नहीं है कि दृश्य नियंत्रण एक का उपयोग कर रहा है ViewModel)।

यदि अतिरिक्त इसे साफ करने के तरीके हैं तो मैं अतिरिक्त विचारों का स्वागत करता हूं। यह अभी भी मुझे स्पष्ट नहीं है कि ViewModel के लिए यह कितना ज़िम्मेदारी है 'ठीक है'।

+2

हम अपने काम पर लगातार इस तरह के प्रश्न पूछते हैं। आपने इस सवाल को बहुत अच्छी तरह से कहा है, इसलिए मुझे आशा है कि आपको यहां कुछ अच्छी प्रतिक्रिया मिलेगी। –

+2

शुक्र है कि यह एक पालतू परियोजना है, इसलिए मेरे पास विभिन्न डिज़ाइनों की खोज करने की लक्जरी है। मेरी दुकान ने डब्ल्यूपीएफ या एमवीवीएम को अपनाया नहीं है क्योंकि इस शुरुआती चरण में ओवरहेड और अजीबता हमारे वर्तमान कार्यक्रमों के लिए स्वीकार्य नहीं है। मैं दृढ़ता से विश्वास है कि यह एक ऐसी तकनीक है उत्पादकता में बड़ा लाभांश का भुगतान करेगा एक बार हम समझते हैं कि यह कैसे उपयोग करने के लिए है, लेकिन यह परिप्रेक्ष्य में इस तरह के एक बदलाव है कि यह जानते हैं कि एक डिजाइन में रेखाएं करने के लिए कठिन है। –

उत्तर

3

व्यूमोडेल के बीच बातचीत के लिए अच्छी तरह से काम करने वाला एक विकल्प सीधे दृश्यमान कक्षाओं के बीच बैठे observer कक्षाओं से जुड़ना है।

+0

लिंक के लिए धन्यवाद; मैं वास्तव में अन्य समन्वय के लिए इस तरह के पैटर्न का उपयोग कर रहा था, एक IMainViewModel सेवा साझा करके, जो मेरे मेन व्यू मॉडेल द्वारा कार्यान्वित किया गया है। मैं सोच रहा हूं कि इसे फिर से प्रतिक्रिया देने के लिए समझदारी हो सकती है ताकि 'साझा' कार्यक्षमता मुख्य विंडो के लिए मॉडल में बंधी न हो और इसके बजाय, मुख्य ऑब्सर्वर है। –

+1

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

3

मुझे लगता है कि आप अपने शीर्ष-स्तर ViewModel को NestedViewModel के अस्तित्व के बारे में जानते हैं, यह एक पदानुक्रमित दृष्टिकोण से समझ में आता है, मास्टर व्यू में बच्चे का दृश्य होता है।

मेरी राय में, आपकी सहजता सही है, यह शीर्ष स्तर पर उपयोगकर्ता क्रियाओं द्वारा शुरू किए गए व्यवहारों का पर्दाफाश करने के लिए नेस्टेड व्यू मॉडेल के लिए सही नहीं लगता है। इसके बजाए, शीर्ष-स्तर ViewModel उस दृश्य के लिए व्यवहार प्रदान करना चाहिए जो इसके साथ जुड़ा हुआ है।

लेकिन मैं कनेक्शन निर्माण के लिए ICommand में ज़िम्मेदारी ले जाने पर विचार करता हूं, और इस आदेश को अपने शीर्ष-स्तर ViewModel के माध्यम से उजागर करता हूं। अपने मास्टर डायलॉग पर ओके बटन तब आप इस कमांड से जुड़ जाएंगे, और कमांड केवल शीर्ष-स्तरीय ViewModel पर प्रतिनिधि होगा, उदाहरण के लिए, ViewModel.CreateConnection() को निष्पादित होने पर कॉल करें।

अपने नेस्टेड नियंत्रण की जिम्मेदारी तो विशुद्ध रूप से एकत्र करने और युक्त ViewModel द्वारा अपने NestedViewModel करने के लिए डेटा को उजागर, उपभोग के लिए है, और यह विभिन्न संदर्भों है कि एक ही जानकारी की आवश्यकता होती दर्ज किए जाने की में सैद्धांतिक रूप से अधिक फिर से प्रयोग करने योग्य है (यदि कोई भी) - मान लीजिए कि आप इसे पहले से बनाए गए कनेक्शन को संपादित करने के लिए पुनः उपयोग करना चाहते हैं।

केवल शिकन होगा अगर NestedViewModel के विभिन्न प्रकार के डेटा का एक बिल्कुल भिन्न सेट का पर्दाफाश होगा।

उदाहरण के लिए, एक को उजागर करता है होस्टनाम और पोर्ट गुण के रूप में, और एक अन्य को उजागर करता है उपयोगकर्ता नाम और पासवर्ड

इस मामले में आपको अपने आधार-स्तर ViewModel.CreateConnection() को अभी भी एक साफ तरीके से काम करने के लिए कुछ आधारभूत कार्य करने की आवश्यकता हो सकती है। हालांकि अगर आप नेस्टेड नियंत्रण प्रकार की एक छोटी राशि है, यह प्रयास के लायक नहीं हो सकता है, और एक सरल NestedViewModel प्रकार की जांच और कलाकारों के लिए पर्याप्त हो सकता है।

इस ध्वनि व्यवहार्य करता है?

+0

चुनौती है कि यहाँ बाहरी ViewModel वास्तव में संकलन समय पर अपने InnerViewModel के प्रकार के बारे में पता नहीं है। कंट्रोलर को रनटाइम पर एप्लिकेशन के एक्सटेंशन के रूप में लाया जाता है, जिसमें कस्टम डेटा टेम्पलेट चयनकर्ता के माध्यम से विशिष्ट नेस्टेड नियंत्रण को तार करने के लिए हुड के नीचे कुछ प्रकार की खोज होती है। मुझे पता है कि डेटाकॉन्टेक्स्ट निश्चित रूप से विशिष्ट नेस्टेड व्यू मॉडेल होगा, लेकिन मुझे डेटाकॉन्टेक्स्ट का निरीक्षण करने के लिए हैकिश लगता है और इसे साझा इंटरफेस में डालने का प्रयास करता है। –

0

मैं हाल ही में निर्भरता इंजेक्शन का उपयोग करने के एकता (माइक्रोसॉफ्ट उद्यम पुस्तकालय) के साथ प्रयोग किया। यह इंटरफेस का उपयोग करते समय जाने का मार्ग हो सकता है जो पूरी तरह से परिभाषित करता है कि दोनों व्यूमोडल्स को एक-दूसरे से क्या नहीं चाहिए। एमईएफ निर्भरता इंजेक्शन के लिए एक और विकल्प होगा जिसे मैं जानता हूं।

एचटीएच

+0

धन्यवाद, मैं वास्तव में इस एप्लिकेशन में एमईएफ का उपयोग कर रहा हूं और इसने यूआई की बहुत समृद्ध विस्तारशीलता की अनुमति देने में काफी मदद की है। यह विस्तारशीलता है जो डिजाइन चुनौतियों का निर्माण करती है, क्योंकि अब यूआई नियंत्रणों को होस्ट कर रहा है, जो वास्तव में लगभग कुछ भी नहीं जानता है।मैं वास्तव में ऐसा करने के लिए एक क्लीनर तरीके से आया हूं, जो आज मैं घर आने के बाद और अधिक जानकारी दूंगा। –

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