किसी दिए गए MVVM एप्लिकेशन में फ्रेमवर्क (Caliburn.Micro, आदि) का उपयोग नहीं करने का विकल्प कैसे चुनें?

Question

मैंने एक बार एक MVVM / WPF परियोजना शुरू की है, जिसे अंततः बनाया और तैनात किया गया था, और इसके लिए मैंने बहुत सारे Caliburn.Micro MVVM फ्रेमवर्क का अध्ययन किया। तथ्य यह है: मैंने उस के लिए कैलिबर्न.माइक्रो का उपयोग नहीं किया , और कुछ एमवीवीएम अवधारणाओं को खुद (विशेष रूप से, बस ViewModelBaseऔर RoutedCommandकक्षाओं) को लागू करने के लिए समाप्त कर दिया ।

अब मुझे उसी तर्ज पर एक बड़े प्रोजेक्ट के लिए सौंपा गया: एक "सिंगल-यूजर रिच क्लाइंट ऑफलाइन डेस्कटॉप एप्लिकेशन", इसलिए कहने के लिए, और मैंने कैलिबर्न.माइक्रो का उपयोग करने का फैसला किया। और यहीं से मेरी "समस्या" शुरू होती है।

मैंने इस प्रसिद्ध ब्लॉग पोस्ट में पढ़ा है , जिसका शीर्षक कहता है कि "यदि आप MVVM का उपयोग कर रहे हैं तो आपको एक रूपरेखा की आवश्यकता है",:

"एमवीवीएम की तरह एक फ्रेमवर्क के बिना कुछ करने की कोशिश करना बहुत बड़ी मात्रा में काम है। डुप्लिकेट कोड के टन, पहिया को फिर से मजबूत करना , और लोगों को अलग तरह से सोचने के लिए फिर से शिक्षित करना ।

कम से कम एक रूपरेखा के साथ आप डुप्लिकेट कोड से बचते हैं और उम्मीद करते हैं कि आपको पहिया को फिर से नहीं करना होगा - जिससे आप लोगों को फिर से शिक्षित करने पर ध्यान केंद्रित कर सकें। रीट्रेनिंग हिस्सा आम तौर पर अपरिहार्य है, लेकिन एक रूपरेखा नलसाजी कोड और संरचना प्रदान करती है, जिससे प्रक्रिया आसान हो जाती है। "

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

यह उल्लेख नहीं करने के लिए कि किसी भी उपर्युक्त-तुच्छ परिदृश्य में IoC कंटेनर शामिल हैं, जो कि मैंने कभी भी काम नहीं किया है, और जो एक समस्या को हल करने के लिए लगता है जो मेरे पास भी नहीं है । मुझे अपनी समस्या और एप्लिकेशन डोमेन के बारे में सोचने के बजाय उन चीजों को सीखने में अधिक प्रोजेक्ट घंटे खर्च करने का मन नहीं है। मैं सिर्फ एक केला चाहता था, लेकिन सीएम ने मुझे एक गोरिल्ला (IoC) दिया जो केले की एक टोकरी पकड़ा था।

अब जब मैं अपने होमस्पून MVVM ढांचे में वापस जाने पर विचार कर रहा हूं - केवल कुछ मुट्ठी भर MVVM- विशिष्ट वर्गों से बना हूं जिन्हें मैं वास्तव में लागू करना चाहता हूं - मैं कम से कम सीएम को मौका देना चाहूंगा, अगर मैं यहां कुछ खो रहा हूं, या बस स्पष्ट रूप से "गलत तरीके से" चीजें करना सरासर अनुभवहीनता और अज्ञानता है। और इसलिए प्रश्न यह है:

व्यापक रूप से आम सहमति है कि "रूपरेखा चीजों को आसान और अधिक प्राकृतिक बनाती है", लेकिन अगर मैं काफी विपरीत अनुभव कर रहा हूं, तो क्या इसका मतलब यह है कि मुझे फ्रेमवर्क का उपयोग नहीं करना चाहिए, या मैं इसे गलत तरीके से सीखने की कोशिश कर रहा हूं? वहाँ एक सुराग है कि मैं भी पहली जगह में एक रूपरेखा का उपयोग नहीं किया जाना चाहिए? या वहाँ कुछ "सही" तरीका है यह जानने के लिए कि सरल एमवीवीएम विकास के लिए सीएम का उपयोग कैसे करें?

Comments

व्यक्तिगत रूप से मैं विशिष्ट व्यवहार के लिए उपयोग करने के लिए प्रत्येक फ्रेमवर्क से आइटम उठाता हूं और चुनता हूं, और मैं बाकी चीजों को अनदेखा करता हूं। उदाहरण के लिए, मुझे Microsoft PRISM का उपयोग EventAggregatorमैसेजिंग के लिए, और NotificationObjectएक ViewModelBase के लिए, और MVVM लाइट का RelayCommandकमांड के लिए उपयोग करना पसंद है। महत्वपूर्ण बात यह है कि यह पहचानना कि आपके लिए क्या समस्याएं हल हो रही हैं, और केवल उन समाधानों का उपयोग करें। ऐसा महसूस न करें कि आप पूरे ढांचे के पुस्तकालय का उपयोग करने के लिए मजबूर हैं।

— राहेल

@Rachel मैं इस दृष्टिकोण का उपयोग करने के लिए Caliburn.Micro के साथ योजना बना रहा था, लेकिन एक RelayCommandकार्यान्वयन नहीं मिल सका (क्योंकि यह ICommand संपत्तियों के लिए बाध्य करने के बजाय, सम्मेलन द्वारा सीधे तरीकों से "बांधता है")।

— हेलटनबिकर

मैंने कभी भी Caliburn फ्रेमवर्क का उपयोग नहीं किया है क्योंकि मुझे यह पसंद नहीं था कि मॉडल / ViewModel लेयर पर व्यू को टाई करने के लिए यह कितना निकट लगता था। आपके मामले में, मुझे कोई कारण नहीं दिखता है कि RelayCommandअगर आप Caliburn Micro द्वारा उपयोग किया गया कोई अन्य पुस्तकालय से उपयोग नहीं कर सकते हैं तो यह आपके लिए काम नहीं करता है।

— राहेल

@Rachel "कितनी नज़दीक [शांत]] दृश्य को एमवीएम परत से जोड़ता है", क्या सही मतलब है आपका? उन परतों को बेहतर, अधिक MVVM तरीके से बांधने का "गैर-शांत" तरीका क्या होगा? (मैं ईमानदारी से पूछता हूं क्योंकि मुझे वर्तमान में नहीं पता है)।

— हेल्टनबिकर

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

— राहेल

Answer 1

मैंने CaliburnMicro और MVVMLight की कोशिश की है और जब Caliburn का उपयोग कर रहा हूं तो मुझे वास्तव में आपको जो महसूस हो रहा है, यकीन है कि यह सिर्फ पुराने पाठ के बजाय नाम = "संपत्तिनाम" का उपयोग करके संपत्ति पर नियंत्रण को बांधने में वास्तव में जादुई महसूस करता है = "{{ind PropertyName}" लेकिन एंड कैलीबर्न इस जादुई चीज़ को करने के लिए ओवरबोर्ड जाता है, जब कुछ गलत हो जाता है तो वास्तव में डिबग करना मुश्किल हो जाता है, बात को बदतर बनाने के लिए उनके पास एक काम करने का बहुत तरीका है।

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

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

Comments

क्या आपको लगता है कि तब, मुझे कम से कम MVVMLight को "Caliburn.Micro भटकाव" से "इलाज" के कुछ प्रकार के रूप में उपयोग करने की कोशिश करनी चाहिए? अगर ऐसा है तो मैं निश्चित रूप से इस पर विचार करूंगा।

— हेलटनबीकर

@heltonbiker निश्चित रूप से, यह एक जाने दे। यह इतना सरल है कि आपको कम से कम एमवीवीएम फ्रेमवर्क पर एक अच्छा पैर जमाना चाहिए।

— किरी

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

— रोल करता है

Answer 2

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

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

Comments

इसके अतिरिक्त, Microsoft द्वारा पेश किए गए MVVM (बॉक्स से बाहर, WPF) की बहुत कमी है। अनुभवी प्रोग्रामर के लिए भी बहुत निराशा होती है जो अनुभवी डेवलपर्स के रूप में खुद को (और ठीक ही ऐसा) सोचते हैं। जादू तार, क्रम में अस्पष्ट अपवाद हैं, इस तरह के तरह एक enum दिखता को radiobuttons के एक समूह के रूप में बाध्यकारी सबसे बुनियादी सामान stackoverflow.com/q/397556/168719 - चौखटे क्या कर सकता है? उन्हें या तो जटिलता के इस स्तर को प्रतिध्वनित करना है, या इस पर एक बहुत मोटी अमूर्तता प्रदान करने का प्रयास करना है

— कोनराड मोरावस्की

@KonradMorawski WPF अपने आप में MVVM नहीं है; आप WPF के साथ कोड कर सकते हैं, लेकिन वह MVVM नहीं है। इसलिए यदि आप डब्ल्यूपीएफ और एमवीवीएम करना चाहते हैं, तो आपको एमवीवीएम फ्रेमवर्क का उपयोग करना होगा या स्वयं को लागू करना होगा।

— एंडी

निश्चित रूप से @Andy, लेकिन यह है कि WPF है कहना सुरक्षित इरादा MMVM के लिए। मैं MVVM कार्यक्षमता की बात कर रहा हूँ जो WPF के साथ बिल्ट-इन होती है। मुझे पता है कि आप अभी भी पीछे कर सकते हैं

— कोनराड मोरावस्की

@KonradMorawski आप MVVM के साथ WPF का उपयोग कर सकते हैं, और उन्होंने इसे विश्वास में मन में संभावना के साथ बनाया है, लेकिन कोई MVVM विशिष्ट कार्यक्षमता WPF में निर्मित है। जैसे आप WinForms के साथ MVP का उपयोग कर सकते हैं, लेकिन WinForms विशेष रूप से उस पैटर्न का उपयोग करने के लिए कुछ भी नहीं प्रदान करता है, जो आपके ऊपर है।

— एंडी

@ और शायद हम अब परिभाषाओं पर बहस कर रहे हैं। मेरा मतलब है कि सभी "गोंद" जो MVVM को संभव बनाता है, पहले से ही है - XAML में डेटा बाइंडिंग, DataContextआदि

— कोनराड मोरावस्की

Answer 3

WPF के साथ मेरा पहला अनुभव Caliburn.Micro का उपयोग कर रहा है, इसलिए यह संभवतः अधिकांश डेवलपर्स से काफी अलग है। मैंने WPF और Caliburn.Micro दोनों को पाया है, जो कि काफी मजबूत सीखने की अवस्था है, WinForms से आती है, हालांकि दोनों के साथ कुछ अनुभव के बाद मैंने उन्हें एक जोड़ी के रूप में उपयोग करने का आनंद पाया है। वर्तमान में एक अलग संगठन में काम कर रहे हैं जहां Caliburn.Micro का उपयोग नहीं किया जाता है मुझे लगता है कि डुप्लिकेट नलसाजी कोड का एक बहुत कुछ है जो कोडबेस को काफी फूला हुआ और अनावश्यक रूप से जटिल बनाता है।

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

Caliburn.Micro भी स्टॉक को अवैध नहीं करता है WPF - यह सिर्फ इसके ऊपर बनाता है, जिसका अर्थ है कि आप अभी भी WPF सुविधाओं का उपयोग कर सकते हैं यदि आप चाहें और यदि आप चाहें तो कुछ बिट्स और टुकड़ों के लिए कैलिबर्न का उपयोग कर सकते हैं। यह मेरे दिमाग में टाइपस्क्रिप्ट और जावास्क्रिप्ट सह-अस्तित्व के समान है।

अगर मुझे मौका दिया जाता है तो मैं निश्चित रूप से भविष्य में काम करने वाले किसी भी नए डब्ल्यूपीएफ प्रोजेक्ट में कैलिबर्न.माइक्रो का उपयोग करूंगा।

Comments

आपके उत्तर के लिए धन्यवाद। दो साल बाद, मुझे डिपेंडेंसी इंजेक्शन कंटेनरों की अवधारणा को समझने के बाद इन रूपरेखाओं को "स्वीकार" करना बहुत आसान लगा, जो मैंने उत्कृष्ट मार्क सेमैन की "DI इन .NET" पुस्तक से सीखा।

— हेलटनबीकर

Answer 4

जो कोई भी Caliburn.Micro के साथ निराशा से बाहर यहाँ आता है, इस ढांचे पर एक नज़र है: स्टाइललेट

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

इसके अलावा, स्टाइललेट एक ViewModel-First दृष्टिकोण लेता है। Caliburn.Micro और कई अन्य चौखटे एक व्यू-फर्स्ट दृष्टिकोण लेते हैं, जो कुछ अजीब समस्याओं के साथ आता है। यदि आप एसओएलआईडी सिद्धांतों और पैटर्न कोड में पहले से ही बहुत अच्छे हैं, तो आपको व्यू मॉडल-पहले दृष्टिकोण को अधिक स्वाभाविक रूप से ढूंढने की संभावना है क्योंकि यह परिप्रेक्ष्य लेता है कि आपके तर्क को सिस्टम को ड्राइव करना चाहिए - दृश्य नहीं।