मैं WPF के लिए एमवीवीएम के बारे में बहुत प्रचार सुन रहा हूं।
हम इसका इस्तेमाल कब करते हैं?
क्या यह सब कुछ के लिए उपयोग है या क्या इसमें केवल विशिष्ट उपयोग हैं?
क्या यह हर परियोजना के लिए लायक है?हम एमवीवीएम का उपयोग कब करते हैं?
यह किसी भी प्रोजेक्ट में उपयोगी हो सकता है, लेकिन मुझे उन स्थितियों में विशेष रूप से सहायक लगता है जहां व्यापार तर्क, इंटरैक्शन तर्क और उपयोगकर्ता इंटरफ़ेस के बीच एक स्पष्ट अलगाव प्रदान करना आवश्यक है (बड़े डेवलपर्स/डिज़ाइनर से जुड़े बड़े एप्लिकेशन या एप्लिकेशन)।
मॉडल = व्यापार तर्क
ViewModel = इंटरेक्शन तर्क
देखें = उपयोगकर्ता इंटरफेस
एमवीवीएम के लिए कई अन्य उपयोग निस्संदेह हैं, लेकिन यह विशेष परिदृश्य वह है जिसे मैंने अपने स्वयं के WPF विकास अनुभव में सबसे उपयोगी पाया है।
मुझे अपेक्षाकृत छोटी परियोजनाओं में भी उपयोगी पाया गया है, अगर मैं डाटाबेसिंग और ऑब्जेक्ट डेटा मॉडल/मॉडल का बहुत अधिक उपयोग कर रहा हूं।
डब्ल्यूपीएफ और सिल्वरलाइट के संदर्भ में?
सब कुछ के लिए सिद्धांत में - प्रत्येक गैर-तुच्छ परियोजना (और संभवतः तब भी)। व्यापक प्रक्रिया का यह हिस्सा (यह चिंताओं को अलग करता है और परीक्षण और अन्य अच्छी चीजों के लिए अनुमति देता है)। असल में यदि आप इसे करने जा रहे हैं (और मुझे लगता है कि आप शायद चाहते हैं, मैं निश्चित रूप से नई परियोजनाओं के साथ इरादा करना चाहता हूं) तो आपको बोर्ड में इसे काफी करना चाहिए।
यदि आप पहले से नहीं हैं, तो यहां से जुड़े वीडियो को देखें: http://blog.lab49.com/archives/2650 - मुझे अपने विचार सीधे प्राप्त करने में बहुत मदद मिली।
पूछने के लिए बेहतर: जब नहीं है तो आप इसका उपयोग करते हैं? सबसे स्पष्ट उदाहरण यह है कि जब डेटा बाध्यकारी उचित नहीं है और आपको सीधे कोड में दृश्यों के तत्वों का उपयोग करना होगा - उदाहरण के लिए, आपके आवेदन को वास्तविक समय में सैकड़ों या हजारों दृश्य तत्वों की दृश्य स्थिति को अपडेट करने की आवश्यकता है डेटा बाइंडिंग के ऊपरी हिस्से को बर्दाश्त करने में सक्षम नहीं है।
मैं वर्तमान में एक बड़ी परियोजना पर काम कर रहा हूं, जहां हम सिल्वरलाइट में एमवीवीएम, सीएएल (समग्र आवेदन मार्गदर्शन) लागू करते हैं। बेशक, चिंताओं को अलग करने का स्तर बहुत अधिक है .. लेकिन
1) कोड बहुत मजबूत हो जाता है।
2) एमवीवीएम छोटी परियोजनाओं (इंटरनेट पर इन सभी हैलो-दुनिया के नमूने) के लिए बहुत अच्छा लग रहा है, लेकिन यह आपके अवसरों को कम करता है: उदाहरण के लिए, रूटेड घटनाएं (महान उपकरण) अभी भी घटनाएं हैं, लेकिन, जैसा कि आप जानते हैं, अगर आप एमवीवीएम का पालन करना चाहते हैं तो इसे सीधे उपयोग करने के लिए सख्ती से मना किया जाता है)।
3) कमांड बाध्यकारी अभी भी Silverlight (.net4.0, vs2010) में ठीक से काम नहीं करता है। यह एक लंबी कहानी है, बस उस आश्चर्य को ध्यान में रखें, जब आपका CanExecute प्रतिनिधि ऐप शुरू होने पर आग नहीं लगाएगा।
आपके प्रश्न का एक अच्छा जवाब है "एमवीवीएम सरल यूआई तर्क के साथ परियोजनाओं के लिए अच्छा है"।
धन्यवाद, इलिया।
हर बार जब मैं एक साधारण परियोजना पर शुरू करने और लगता है कि "यह बहुत आसान है, MVVM overkill होगा", मैं कहाँ पता है कि MVVM का उपयोग कर बातें ज्यादा सरल बनाना होगा लगभग 8 घंटे बाद मैं एक बात करने के लिए मिलता है।
तो मैं कहूंगा कि एमवीवीएम का उपयोग करने में अधिकांश समय वास्तव में आपके यूआई तर्क को सरल बना देगा, भले ही आप शुरू में सोचें कि यह अधिक हो जाएगा। परियोजनाओं के समय के साथ और अधिक जटिल होने की आदत है, और व्यापार तर्क को अलग करना और एमवीवीएम द्वारा लागू तर्क को देखने से परियोजना को आपके व्यापार और यूआई तर्क को एक साथ मिश्रित करने से कहीं अधिक नियंत्रित तरीके से विकसित किया जा सकता है।