क्या MVVM व्यर्थ है? [बन्द है]


91

रूढ़िवादी MVVM कार्यान्वयन व्यर्थ है? मैं एक नया एप्लिकेशन बना रहा हूं और मैंने विंडोज फॉर्म और डब्ल्यूपीएफ पर विचार किया। मैंने WPF को चुना क्योंकि यह भविष्य का सबूत है और बहुत सारे लचीलेपन की पेशकश करता है। XAML का उपयोग करके अपने UI में महत्वपूर्ण परिवर्तन करने के लिए कम कोड और आसान है।

चूंकि WPF के लिए विकल्प स्पष्ट है, मुझे लगा कि मैं MVVM का उपयोग करके अपने आवेदन आर्किटेक्चर के रूप में सभी तरह से जा सकता हूं क्योंकि यह मिश्रण क्षमता, पृथक्करण चिंताओं और इकाई परीक्षणशीलता प्रदान करता है। सैद्धांतिक रूप से, यह यूआई प्रोग्रामिंग की पवित्र कब्र की तरह सुंदर लगता है। यह संक्षिप्त साहसिक; हालाँकि, वास्तविक सिरदर्द में बदल गया है। जैसा कि अभ्यास में अपेक्षित था, मुझे लग रहा है कि मैंने एक समस्या को दूसरे के लिए व्यापार किया है। मैं एक जुनूनी प्रोग्रामर बन गया हूं, मैं चीजों को सही तरीके से करना चाहता हूं ताकि मैं सही परिणाम पा सकूं और संभवत: एक बेहतर प्रोग्रामर बन सकूं। MVVM पैटर्न ने उत्पादकता पर मेरे परीक्षण को रोक दिया और अभी एक बड़ी yucky हैक में बदल गया है!

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

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

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


6
मैंने हमेशा सवाल किया है कि MVVM ओवर इंजीनियरिंग है या नहीं। दिलचस्प सवाल।
टेलर लेसे

11
एमवीवीएम और एमवीसी जैसे पैटर्न ओवररेंजिंग की तरह लगते हैं, जब तक आपको कुछ संशोधन करने या किसी घटक को बदलने की आवश्यकता नहीं होती है। पहली बार जब आपको ऐसा करना होगा, तो सभी समारोह अपने लिए भुगतान करेंगे।
रॉबर्ट हार्वे

41
लंबोदर गूढ़ हैं? मुझे खबर है।
रे बोयसेन

5
@Ray - Haha, +1 उस टिप्पणी के लिए! : डी
वेनमो

7
जैसा कि एलन कूपर ने लगभग एक दशक पहले फेस के बारे में बताया था , यदि आप यूआई डिजाइन कर रहे हैं और मोडल संवाद एक किनारे का मामला नहीं है, तो आप शायद कुछ गलत कर रहे हैं।
रॉबर्ट रॉसनी

जवाबों:


61

क्षमा करें यदि मेरा जवाब थोड़ा सुस्त हो गया है, लेकिन मुझे दोष मत दो! आपका प्रश्न लंबा भी है।

सारांश में, MVVM व्यर्थ नहीं है।

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

हाँ, यह वास्तव में है।
हालाँकि, MVVM आपको यूआई के स्वरूप को उसके लॉगिक्स से अलग करने का एक तरीका प्रदान करता है। कोई भी आपको हर जगह इसका इस्तेमाल करने के लिए मजबूर करता है, और कोई भी आपके माथे के खिलाफ बंदूक नहीं रखता है ताकि आप हर चीज के लिए एक अलग व्यूमॉडल बना सकें।

यहाँ इस विशेष उदाहरण के लिए मेरा समाधान है:
UI एक निश्चित इनपुट को कैसे संभालता है, यह ViewModel का व्यवसाय नहीं है। मैं View .xaml.cs फ़ाइल में कोड जोड़ दूंगा, जो डायलॉग बॉक्स को तत्काल बदल देता है और इसके DataContext के रूप में समान ViewModel उदाहरण (या यदि आवश्यक हो, तो) सेट करता है।

MVVM पैटर्न से लाभ उठाने के लिए, आपको अपने आवेदन की परतों में कई स्थानों पर कोड वितरित करना होगा। आपको टेम्प्लेट प्रोग्रामिंग प्रोग्रामिंग जैसे टेम्प्लेट और लांबा एक्सप्रेशंस का भी उपयोग करना होगा।

ठीक है, आपको इसे कई स्थानों पर उपयोग करने की आवश्यकता नहीं है। यह है कि मैं इसे कैसे हल करेंगे:

  • XAML को व्यू में जोड़ें, और .xaml.cs में कुछ भी नहीं
  • एक ViewModel के अंदर हर ऐप लॉजिक (सामान को छोड़कर जो सीधे UI तत्वों के साथ काम करेगा) लिखें
  • सभी कोड जो यूआई द्वारा किए जाने चाहिए, लेकिन व्यावसायिक तर्क से कोई लेना-देना नहीं है ।xaml.cs फ़ाइलों में जाता है

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

(BTW, टेम्प्लेट और लैम्ब्डा एक्सप्रेशन सही उपयोग किए जाने पर गूढ़ नहीं हैं। लेकिन यदि आप नहीं चाहते हैं, तो उनका उपयोग न करें।)

सामान जो आपको स्क्रीन पर अपने सिर को खरोंचते हुए घूरता है।

हाँ, मैं भाव जानता हूँ। वास्तव में जब मैं पहली बार MVVM को देख रहा था तो मैं क्या महसूस कर रहा था। लेकिन एक बार जब आप इसे लटका लेते हैं, तो यह अब बुरा नहीं लगेगा।

मैं एक बॉक्स के बारे में ठीक काम कर रहा था ...

आप ViewModel को एक बॉक्स के पीछे क्यों रखेंगे? उसका कोई मतलब नहीं।

MVVM टूलकिट में से अधिकांश डायलॉग पर चमकते हैं और जब वे उन्हें संबोधित करते हैं, तो वे केवल सतर्क बॉक्स होते हैं जिन्हें कस्टम इंटरफेस या व्यू मॉडल की आवश्यकता नहीं होती है।

हां, क्योंकि बहुत तथ्य यह है कि एक यूआई तत्व एक ही खिड़की, या किसी अन्य खिड़की में है, या इस समय मंगल की परिक्रमा कर रहा है, व्यूमाडेल्स की कोई चिंता नहीं है।
चिंताओ का विभाजन

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

यहाँ एक बहुत अच्छा वीडियो है, जिसका शीर्षक बिल्ड एमवीवीएम फ्रेमवर्क है । यह देखने लायक है।


2
अंतिम तीन शब्दों के लिए +1। लेकिन बाकी का जवाब भी अच्छा है। :)
रॉबर्ट हार्वे

12
कोड-पीछे का उपयोग करने के बारे में सलाह के लिए +1। यह एक आम गलत धारणा है कि MVVM में कोड-पीछे का उपयोग करना "बुरा" है ... लेकिन विशुद्ध रूप से UI से संबंधित सामान के लिए, यह जाने का तरीका है।
थॉमस लेवेस्क

@ थोमस: हाँ, मैं और अधिक सहमत नहीं हो सकता। मैंने कई कार्यान्वयन देखे हैं जहां लोग सभी कोड (यहां तक ​​कि यूआई-संबंधित) को ViewModel में डालते हैं, क्योंकि (उनके अनुसार) "वह है जहां कोड है"। यह काफी हैकिंग था।
वेनमो

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

7
@ थॉमस: आप सही हैं, MVVM के बारे में सबसे बड़ा मिथक है कि MVVM का उद्देश्य कोड-पीछे छूटना है। इसका उद्देश्य गैर-यूआई महासागर को पीछे के कोड से बाहर निकालना है। ViewModel में यूआई-ओनली कोड डालना कोड-बैक में समस्या डोमेन कोड डालने के समान ही बुरा है।
जिम रेबेरानी

8

इसे काम में लाना मुश्किल है। MVVM पैटर्न से लाभ उठाने के लिए, आपको अपने आवेदन की परतों में कई स्थानों पर कोड वितरित करना होगा। आपको टेम्प्लेट प्रोग्रामिंग प्रोग्रामिंग जैसे टेम्प्लेट और लांबा एक्सप्रेशंस का भी उपयोग करना होगा।

एक सामान्य मॉडल संवाद बॉक्स के लिए? आप निश्चित रूप से वहाँ कुछ गलत कर रहे हैं - एमवीवीएम कार्यान्वयन को उस जटिल होना जरूरी नहीं है।

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

MVVM, MVC, डॉक्यूमेंट-व्यू, आदि पैटर्न का एक पुराना परिवार है। कमियां हैं, लेकिन आप जिस तरह का वर्णन करते हैं, उसका कोई भी घातक दोष नहीं है।


5

मैं PRISM का उपयोग करते हुए एक काफी जटिल MVVM विकास के बीच में हूं इसलिए मुझे पहले से ही इस तरह की चिंताओं का सामना करना पड़ा।

मेरे व्यक्तिगत निष्कर्ष:

MVVM बनाम MVC / पॉपअप और सह

  • MVVM वास्तव में एक बेहतरीन पैटर्न है और ज्यादातर मामलों में यह पूरी तरह से WPF में शक्तिशाली डेटा बाइंडिंग के लिए MVC की जगह लेता है
  • प्रस्तुतकर्ता से सीधे आपकी सेवा परत को कॉल करना ज्यादातर मामलों में एक वैध कार्यान्वयन है
  • यहां तक ​​कि काफी जटिल सूची / डिटेल परिदृश्य शुद्ध एमवीवीएम के लिए {बाइंडिंग पथ = /} सिंटैक्स के लिए धन्यवाद द्वारा लागू किए जा सकते हैं
  • फिर भी, जब कई विचारों के बीच जटिल समन्वय को लागू करने की आवश्यकता होती है, तो एक नियंत्रक अनिवार्य है
  • घटनाओं का उपयोग किया जा सकता है; पुराने पैटर्न जो नियंत्रक में IVIV (या AbstractObserver) के उदाहरणों को संग्रहीत करता है, अप्रचलित है
  • आईओसी कंटेनर द्वारा प्रत्येक प्रस्तुतकर्ता में नियंत्रक को इंजेक्ट किया जा सकता है
  • प्रिज्म की IEventAggregator सेवा एक और संभावित समाधान है यदि नियंत्रक का एकमात्र उपयोग घटना प्रेषण है (इस मामले में यह नियंत्रक को पूरी तरह से बदल सकता है)
  • यदि विचार गतिशील रूप से बनाए जाने हैं, तो यह नियंत्रक के लिए एक बहुत ही अनुकूल काम है (प्रिज्म में नियंत्रक को एक IRegionManager इंजेक्ट किया जाएगा)
  • मोडल संवाद बॉक्स ज्यादातर आधुनिक कंपोज़िट एप्लिकेशन में अप्रचलित होते हैं, वास्तव में अनिवार्य पुष्टिकरण जैसे ब्लॉकिंग ऑपरेशनों को छोड़कर; इन मामलों में मोडल सक्रियण को कंट्रोलर के अंदर बुलाया जाने वाली सेवा के रूप में अमूर्त किया जा सकता है, और एक विशेष वर्ग द्वारा कार्यान्वित किया जाता है, जो उन्नत प्रस्तुति-स्तरीय इकाई परीक्षण के लिए भी अनुमति देता है। नियंत्रक, उदाहरण के लिए, IConfirmationService.RequestConfirmation ("क्या आप निश्चित हैं") को कॉल करेंगे, जो रनटाइम पर एक मोडल डायल डिस्प्ले को ट्रिगर करेगा और यूनिट टेस्टिंग के दौरान आसानी से मॉक किया जा सकता है।

5

मैं धोखा देकर संवाद मुद्दे से निपटता हूं। मेरा MainWindow एक IWindowServices इंटरफ़ेस लागू करता है जो सभी एप्लिकेशन-विशिष्ट संवादों को उजागर करता है। मेरे अन्य ViewModels तब सेवाओं के इंटरफ़ेस को आयात कर सकते हैं (मैं MEF का उपयोग करता हूं, लेकिन आप आसानी से निर्माणकर्ताओं के माध्यम से इंटरफ़ेस को आसानी से पास कर सकते हैं) और इसका उपयोग करने के लिए यह आवश्यक है कि क्या आवश्यक है। उदाहरण के लिए, यहां इंटरफ़ेस कुछ ऐसा दिखता है जैसे कि मेरा एक छोटा उपयोगिता अनुप्रयोग है:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

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

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


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

इंटरफ़ेस को मेरे ViewModel उदाहरणों में से किसमें इंजेक्ट किया गया है, एप्लिकेशन संवादों तक पहुंच की आवश्यकता है। ज्यादातर मामलों में, मैं संवाद के लिए ViewModel में गुजर रहा हूं, लेकिन मैं थोड़ा आलसी हो गया और फ़ाइल संवाद कॉल के लिए WPF OpenFileDialog और SaveFileDialog का उपयोग करता हूं। मेरा प्राथमिक लक्ष्य इकाई परीक्षण के उद्देश्यों के लिए अलगाव था, इसलिए यह उस लक्ष्य के लिए पर्याप्त है। यदि आप बेहतर अलगाव चाहते थे, तो आप शायद OpenFileViewModel और SaveFileViewModel बनाना चाहेंगे, जो संवादों के लिए आवश्यक गुणों की नकल करेगा।
डैन ब्रायंट

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

5

डिज़ाइन पैटर्न आपकी मदद करने के लिए हैं, बाधा नहीं। एक अच्छा डेवलपर होने का एक छोटा सा हिस्सा यह जान रहा है कि "नियमों को कैसे तोड़ना है"। यदि MVVM किसी कार्य के लिए बोझिल है और आपने निर्धारित किया है कि भविष्य का मूल्य प्रयास के लायक नहीं है, तो पैटर्न का उपयोग न करें। उदाहरण के लिए, जैसा कि अन्य पोस्टरों ने टिप्पणी की है, आप बॉक्स के बारे में एक सरल लागू करने के लिए सभी ओवरहेड के माध्यम से क्यों जाएंगे?

डिज़ाइन पैटर्न का कभी भी हठपूर्वक पालन करने का इरादा नहीं था।


2
सही बात। बॉक्स के बारे में एक सरल होना चाहिए, लेकिन क्या होगा यदि आपको संस्करण, लाइसेंसिंग, रनिंग प्रक्रिया, कंपनी का नाम आदि जैसी जानकारी प्रदर्शित करनी है, यह सब जानकारी है जो कहीं न कहीं रहती है। मानक रूपों में, आप बस उस सभी जानकारी को बांध सकते हैं और उसके साथ किया जा सकता है। MVVM का कहना है कि आपको इसके लिए एक व्यू मॉडल बनाना चाहिए, जो बेमानी है।
ATL_DEV

1

पैटर्न के रूप में ही MVVM महान है। लेकिन NET 4.0 डेटा बाइंडिंग समर्थन के साथ WPF का कंट्रोल लाइब्रेरी शिप बहुत सीमित है, यह WinForm की तुलना में बहुत बेहतर है, लेकिन फिर भी यह बाइंडेबल एमवीवीएम के लिए पर्याप्त नहीं है, मैं कहूंगा कि यह पावर 30% है जो बाइंडिंग एमवीवीएम के लिए आवश्यक है।
Bindable MVVM: यह UI है जहां ViewModel केवल डेटा बाइंडिंग का उपयोग करके View के साथ वायर्ड है।
MVVM पैटर्न ViewState के ऑब्जेक्ट प्रतिनिधित्व के बारे में है, यह वर्णन नहीं करता है कि कैसे आप View और ViewModel के बीच सिंक को बनाए रखते हैं, WPF में यह डेटा बाइंडिंग है लेकिन यह कुछ भी हो सकता है। और वास्तव में आप किसी भी UI टूलकिट में MVVM पैटर्न का उपयोग कर सकते हैं जो इवेंट्स के कॉलबैक का समर्थन करता है, आप इसे WinForms में शुद्ध WinAPI में उपयोग कर सकते हैं (मैंने किया था, और यह इवेंट्स / कॉलबैक के साथ बहुत अधिक काम नहीं है), और आप इसे टेक्स्ट में भी उपयोग कर सकते हैं कंसोल, जैसे एमवीवीएम पैटर्न का उपयोग करते हुए DoS के नॉर्टन कमांडर को फिर से लिखना।

संक्षेप में: MVVM व्यर्थ नहीं है, यह बहुत अच्छा है। NET 4.0 WPF का नियंत्रण पुस्तकालय कचरा है।

यहाँ अवधारणा ViewModel का सरल प्रमाण है जिसे आप WPV का उपयोग करके शुद्ध MVVM तरीके से बाँध नहीं सकते।

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

आप WPF के DataGrid कॉलम हेडर को बाइंड नहीं कर सकते, आप चयनित पंक्तियों, इत्यादि को बाइंड नहीं कर सकते, या तो आप इसे कोड सिंपल तरीके से करेंगे, या सरल ViewMelel की इन 5 लाइनों के लिए XAML हैक कोड की 200 लाइनें लिखेंगे। आप केवल कल्पना कर सकते हैं कि जटिल ViewModels के साथ चीजें कैसे बदतर हो जाती हैं।
तो जब तक आप हैलो वर्ल्ड एप्लिकेशन नहीं लिख रहे हैं, तब तक यह जवाब अनुकरणीय है, WPF में bvable MVVM का उपयोग करना व्यर्थ है। आप अपना अधिकांश समय हैक पर सोचने में खर्च करेंगे ताकि आप ViewModel को बांध सकें। डेटा बाइंडिंग अच्छी है लेकिन 70% समय के लिए वापस आने के लिए तैयार रहें।


आप इसे कन्वर्टर्स के साथ, डेटाग्रिड में बाँध सकते हैं।
कैमरून मैकफारलैंड 15

@CameronMacFarland: सभी नहीं, कुछ गुण आसानी से और unbindable हैं, कुछ बस मौजूद नहीं हैं और केवल घटना की रिपोर्ट स्थिति परिवर्तन हैं।
एलेक्स बर्टसेव

मैं मानता हूँ कि मुझे WPF DataGrid का उपयोग करने का अधिक अनुभव नहीं है। मैं इसे बदसूरत से बचने के लिए करता हूं और अब WPF के साथ फिट नहीं है। कहा कि घटनाओं को संभालने के लिए कन्वर्टर्स और अटैचप्रोपरेटी का एक संयोजन आपको चाहिए जो आपको चाहिए।
कैमरून मैकफारलैंड

1
एलेक्स, आपके द्वारा की जा रही समस्याएं डेटाग्रिड के डिजाइन के साथ हैं, एमवीवीएम के साथ नहीं। यह कहना गलत नहीं है कि "डेटा बाइंडिंग अच्छी है, लेकिन 70% समय के लिए कमबैक के लिए तैयार रहें।" मैंने कुछ वस्तुनिष्ठ रूप से विशाल WPF एप्लिकेशन लिखे हैं जिसमें UI में कोई ईवेंट हैंडलर नहीं हैं - इवेंट हैंडलर के अपवाद के साथ जो कि (टेलरिक) डेटा ग्रिड को आरंभीकरण के लिए आवश्यक है।
रॉबर्ट रॉसनी

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

0

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

मैं इस लेख को पढ़ने का सुझाव देता हूं कि WPM ट्री व्यू को सरल बनाने के लिए ViewModel पैटर्न का उपयोग करके सावधानीपूर्वक देखें कि MVVM को अच्छी तरह से कैसे लागू किया जा सकता है और आपको MVVM में सोचने के नए तरीके से अपनी जीत के रूपों को बदलने की अनुमति देता है। संक्षेप में जब आप कुछ करना चाहते हैं तो ViewModel पर तर्क को लागू करें न कि पहले देखें। आप एक आइटम का चयन करना चाहते हैं? एक आइकन बदलें? UI तत्वों पर पुनरावृत्ति न करें, बस मॉडल गुणों को अपडेट करें और डेटा-बाइंडिंग को किटी ग्रिट्टी करें।


-1

मैंने बहुत से MVVM कार्यान्वयन के साथ एक ही मुद्दा देखा है जब यह (मोडल) संवाद आता है। जब मैं MVVM पैटर्न के प्रतिभागियों को देखता हूं तो मुझे लगता है कि एक सुसंगत अनुप्रयोग बनाने के लिए कुछ गायब है।

  • दृश्य में विशिष्ट GUI नियंत्रण शामिल हैं और उपयोगकर्ता इंटरफ़ेस की उपस्थिति को परिभाषित करता है।
  • ViewModel प्रस्तुति की स्थिति और व्यवहार का प्रतिनिधित्व करता है।
  • डोमेन परत या सेवा से मॉडल एक व्यावसायिक वस्तु हो सकती है जो आवश्यक डेटा प्रदान करती है।

लेकिन लापता है:

  • ViewModels कौन बनाता है?
  • एप्लिकेशन वर्कफ़्लो के लिए कौन जिम्मेदार है?
  • जब वे एक दूसरे के साथ संवाद करने की आवश्यकता होती है, तो ViewModels के बीच मध्यस्थता कौन करता है?

मेरा दृष्टिकोण एक यूज (यूसेज-केस) कंट्रोलर पेश करना है जो लापता बिंदुओं के लिए जिम्मेदार है। यह कैसे काम करता है WPF एप्लीकेशन फ्रेमवर्क (WAF) नमूना अनुप्रयोगों में देखा जा सकता है ।


जोश स्मिथ द्वारा लागू किए गए मध्यस्थ पैटर्न ने मेरे सभी दृश्य मॉडल संचार मुद्दों को हल कर दिया। Messenger.NotifyColleagues ने पूरी तरह से स्वतंत्र दृश्य मॉडल रखने का एक तरीका प्रदान किया, जो जानता था कि वैश्विक घटनाओं (यदि उन्हें परवाह है) के बारे में कोई भी दो दृश्य मॉडल एक-दूसरे के बारे में जाने बिना कैसे जवाब देंगे। यह अब कुछ ही समय पहले हमारे बेकन को बचाया है।
जेसन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.