व्यावसायिक अनुप्रयोग की एक लाइन में MVVM का मूल्य (और वर्तमान विकास प्रथाओं का एक रेंट)

Question

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

हालांकि, मेरा कैरियर ज्यादातर व्यावसायिक अनुप्रयोगों की आंतरिक रेखा के आसपास घूमता है - एक व्यवसाय के संचालन को औपचारिक और अनुकूलित करना। इस तरह के ऐप में आमतौर पर CRUD और कंपाउंड ऑपरेशंस के इर्द-गिर्द घूमने वाला एक बिजनेस टीयर होता है। LOBs में, मेरे विचार मॉडल अंत में बिजनेस क्लास के तरीकों की एक पंक्ति के आवरण कार्यों का एक बहुत ही सरल संग्रह है और अंत में केवल संदेश बॉक्स दिखाने या विंडो खोलने जैसे कार्यों को सरलतम रूप से जटिल करते हैं। क्या किसी और को यह अजीब नहीं लगता, जब लोग विंडो के लिए "निर्भरता इंजेक्शन" और "मैसेजिंग प्रोवाइडर" के लंबे डिस्क्रिप्शन में चले जाते हैं। दशकों के लिए किया गया है। स्टैक ओवरफ्लो पर कितने अन्य प्रश्न हैं जो उन कार्यों के लिए सलाह मांगते हैं जो विनफॉर्म में बेहद सरल थे?

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

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

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

मुझे लगता है कि एक जवाब सिर्फ winforms में रहने के लिए है। लेकिन WebForms के अंतिम समर्थकों में से एक के रूप में (मेरे पास वेब डेवलपमेंट की प्रवृत्ति के समान समालोचना है), मैंने डायनासोर की तरह थोड़ा महसूस किया क्योंकि यह तब होता है जब मुझे लगता है कि Microsoft प्रमाणन पटरियों में अब और कोई WebForms नहीं बचा है। आगे बढ़ना ही एकमात्र विकल्प है, भले ही मुझे यह पसंद न हो।

Comments

हालांकि मैं इसे प्रोत्साहित नहीं करता हूं, फिर भी घटनाओं और कोड के साथ WPF आवेदन WinForms- शैली लिखना संभव है। साधारण वन-ऑफ ऐप्स के लिए, यह कोई बड़ी बात नहीं है। यह नीचे आता है कि आप क्या मूल्य रखते हैं और व्यवसाय को क्या मूल्य प्रदान करता है। मैं TDD और MVVM का बहुत बड़ा प्रशंसक हूं, लेकिन अगर यह वास्तव में मूल्य प्रदान नहीं कर रहा है, तो इसे न करें। यह कोई धर्म नहीं है। बस याद रखें कि कोड अक्सर बहुत लंबे समय तक रहता है जितना हम सोचते हैं कि यह होगा।

— मैट एच

"क्या यह किसी और को अजीब नहीं लगता है जब लोग विंडो के लिए 'निर्भरता इंजेक्शन' और 'मैसेजिंग प्रोवाइडर' के लंबे डिस्क्रिप्शन में चले जाते हैं। दशकों के लिए किया गया है। मुझे यह कष्टप्रद लगता है, लेकिन उस व्यक्ति की तरह जो उस सब में शामिल हो जाता है (वास्तव में कुछ भी करने के लिए कुछ भी हो रहा है) हमेशा क्षेत्र का एक हिस्सा रहा है, और दुर्भाग्य से, शायद हमेशा होगा। सर्वोत्तम रणनीति यह है कि उन्हें जितना संभव हो सके अनदेखा / विचलित करें।

— user1172763

Answer 1

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

Webforms केवल एक ही है, सिवाय इसके कि यह एक स्टेटलेस सिस्टम (वेब) पर स्टेटफुल एब्स्ट्रैक्शन होने की अतिरिक्त पेचीदगी में फेंकता है। जैसा कि रोब कॉनरी ने रखा:

WebForms एक झूठ है। यह अमूर्तता है, जो झूठ की चटनी में लिपटे हुए धोखे में लिपटी हुई है, जो कि डायवर्सन से भरी प्लेट पर प्रस्तुत की गई थी और हाथ की निंदाई थी। आपके द्वारा Webforms के साथ कुछ नहीं करने का वेब से कोई लेना-देना नहीं है - आप इसे आपके लिए काम करने देते हैं।

यह, उस आदमी से जिसने dynamicC # में कीवर्ड का उपयोग करके पूरी तरह कार्यात्मक वस्तु-संबंधपरक मैपर लिखा था और कोड की केवल चार सौ लाइनें। जब वह किसी बात के बारे में आधिकारिक रूप से बोलते हैं, तो मैं सुनता हूं।

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

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

मैं उस कुंजी / मूल्य सूची को ले सकता हूं, और इसे एक्सएमएल में अनुक्रमित कर सकता हूं, जिससे मैं इसे एक फाइल पर बना रह सकता हूं। मेरे पास अन्य रूप हैं जो मैं एक पारंपरिक डीटीओ को सौंप सकता हूं , और इसके खेतों को फॉर्म में मैप कर सकता हूं । इसमें से कोई भी "कीचड़ की बड़ी गेंद" शैली में व्यावहारिक नहीं होगा। जब पर्याप्त डिकॉउलिंग का उपयोग किया जाता है तो यह लगभग तुच्छ होता है।

क्या कोई इस ध्वनि से परिचित है? यह होना चाहिए; यह अनिवार्य रूप से डेटा-बाइंडिंग का एक गरीब-आदमी का रूप है।

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

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

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

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

"बड़े एप्लिकेशन" मॉडल के साथ मेरा वास्तविक अनुभव ASP.NET MVC का उपयोग करने में है। ASP.NET, ASP.NET MVC के लिए है क्योंकि Winforms WPF है। जब मैंने ASP.NET में काम किया, तो मैंने हमेशा अपनी इच्छाशक्ति के आगे झुकने के लिए संघर्ष किया। ASP.NET MVC आपको झुकता है। यह उपयोग करने के लिए एक खुशी है; यह एक प्रणाली संरचना का उत्पादन करता है जो स्पष्ट और व्यवस्थित है, और आपको अपने आवेदन और मार्कअप पर पूर्ण नियंत्रण प्रदान करता है। आप जावास्क्रिप्ट, jQuery और CSS का उदारतापूर्वक उपयोग कर सकते हैं, और ASP.NET MVC आपके रास्ते से बाहर रहता है।

मेरी एकमात्र बाधा यह आदत हो रही थी, और इसे अपनी शर्तों पर जानने के लिए।

आगे पढ़ना
चाहिए आपको रॉ कॉनरी द्वारा MVC सीखना चाहिए

Comments

कीचड़ की ट्रॉली विचारशील प्रतिक्रिया के लिए धन्यवाद - मुझे निश्चित रूप से क्लासिक एस्प और स्पेगेटी कोड के दिनों में ऐसा महसूस हुआ। Vb6 / mts के साथ 3 टियर डिज़ाइन ने बहुत कुछ तय किया और फिर .net की रिलीज़ ने इसे एक साथ ला दिया। लेकिन अब अगर लगता है कि अतिरिक्त पैटर्न पर रिटर्न तेजी से कम हो रहा है - जैसे $ 1M खर्च करना। अपने तिमाही मील के समय को बंद करना। "मैंने आक्रामक रूप से प्रत्येक बिट को एक अलग असेंबली में धकेल दिया था" - क्या आपको नहीं लगता कि यह अविश्वसनीय रूप से खंडित विकास का अनुभव देता है - लगातार दो पंक्तियों को पढ़ने के लिए फ़ाइल से फ़ाइल में कूदना?

— b_levitt

don't you find that this gives an incredibly fractured development experience - constantly jumping from file to file to read two lines?- नहीं, यह विपरीत है। इस तरह एक और असेंबली में डालने से आपका मन अपने स्वयं के छोटे ब्लैक बॉक्स के रूप में प्रत्येक वर्ग और विधि पर ध्यान केंद्रित करने के लिए मुक्त हो जाता है। मिट्टी की एक बड़ी गेंद के साथ ऐसा करना बहुत मुश्किल है। MVC एक ही सिद्धांत पर काम करता है: पतली नियंत्रक, वसा मॉडल, देखने में कोई कोड नहीं जब तक कि बिल्कुल आवश्यक न हो।

— रॉबर्ट हार्वे

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

— रॉबर्ट हार्वे

मैं ASP.NET जीवन चक्र के खिलाफ कुछ भी नहीं है, वैसे; मैंने देखा है कि लोग इसे उत्कृष्ट प्रभाव के लिए उपयोग करते हैं। मुझे बस यह सहज-सरल लगता है, बस। ASP.NET MVC आपको कोई क्लाइंट-साइड डेवलपमेंट करने के लिए बाध्य नहीं करता है, यदि आप नहीं करना चाहते हैं; आप "गूंगा" विचारों का उपयोग कर सकते हैं, और यह पूरी तरह से ठीक काम करता है। वर्थ नोटिंग: इस सामान का एक बहुत कुछ कोड-जनरेट किया जा सकता है (बिल्कुल विंडोज फॉर्म की तरह), इसलिए ऐसा नहीं है कि आप सभी कोड खुद लिख रहे हैं। मैं समझता हूं कि यह WPF के साथ कम सच है, जहां आपको XAML से निपटना है, और मुझे लगता है कि वहां सुधार की गुंजाइश है।

— रॉबर्ट हार्वे

dozens of lines of plumbing to replace Window.Show- यह एक छोटा सा निरीक्षण है। यदि विंडो को डेटा की आवश्यकता होती है, तो उस डेटा को विंडो के नियंत्रण में प्राप्त करने के लिए, और इसके विपरीत, किसी प्रकार का प्लंबिंग होना चाहिए। आप या तो उस दोहराए गए कोड को अपने द्वारा बनाए गए हर फॉर्म के लिए बार-बार लिख सकते हैं, या डेटा बाइंडिंग जैसे सामान्यीकृत समाधान के कुछ फॉर्म को नियोजित कर सकते हैं।

— रॉबर्ट हार्वे