एमवीसी 3 - नियंत्रक और दृश्य मॉडल - जिनमें अधिकांश व्यावसायिक तर्क शामिल होना चाहिए?

Question

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

हालांकि यह एक अच्छा विचार है, अब एक प्रश्न आता है जो नियंत्रकों में अपने व्यावसायिक तर्क को काफी अलग कर सकता है। नियंत्रकों और ViewModels के लिए, जिसमें अधिकांश व्यावसायिक तर्क होना चाहिए?

मैंने अपने व्यूमोडल्स को व्यावहारिक रूप से सभी व्यावसायिक तर्क रखने के कुछ तरीकों का प्रयास किया है। हालांकि, मुझे अपने व्यू मॉडेल के कन्स्ट्रक्टर में एक तर्क होना है जो कार्य का एक इकाई लेता है। यह एक अच्छा विचार है?

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

यहां सबसे अच्छा अभ्यास क्या है?

Answer 1

नियंत्रकों और ViewModels के लिए, जो व्यापार तर्क के सबसे को शामिल करना चाहिए?

इनमें से कोई भी नहीं।

मैंने अपने व्यूमोडल्स को व्यावहारिक रूप से सभी व्यावसायिक तर्क रखने के कुछ तरीकों का प्रयास किया है। हालांकि, मुझे अपने व्यू मॉडेल के कन्स्ट्रक्टर में एक तर्क होना है जो कार्य का एक इकाई लेता है। यह एक अच्छा विचार है?

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

यहां सबसे अच्छा अभ्यास क्या है?

चलिए पहले एमवीसी पैटर्न पर वापस जाएं। यह एक व्यापक परिभाषा है लेकिन यह जानकर आपको यह महसूस करना चाहिए कि आपको कहां रखना चाहिए।

• एमवीसी में "मॉडल" वास्तव में डेटा को खींचने के लिए उपयोग की जाने वाली सभी चीजें हैं। यह webservices, एक व्यापार परत, भंडार आदि हो सकता है

• दृश्य सभी कोड है जो HTML उत्पन्न करता है (चूंकि हम वेब के बारे में बात कर रहे हैं)।

• नियंत्रक को मॉडल और दृश्य के बीच एक गोंद माना जाना चाहिए। इसलिए इसे मॉडल से जानकारी लेनी चाहिए और इसे दृश्य द्वारा उपयोग करने योग्य कुछ में बदलना चाहिए।

कि संरचना के साथ समस्या यह है कि यह करने के लिए "रिसाव" परत में विशेष जानकारी काफी आसान पैटर्न के अन्य भागों में है। इसलिए माइक्रोसॉफ्ट ने एमवीसी के कार्यान्वयन में व्यूमोडल्स पेश किए।

इस तरह हम विचारों से सभी प्रतिपादन तर्क हटा सकते हैं और इसे ViewModel में डाल सकते हैं। इसके बजाय अपने ध्यान में रखते हुए ऐसा करने का:

<span>@(model.Age == 0 ? "n/a" : model.Age)</span> 

आप के बजाय ViewModel के अंदर है कि कोड डाल दिया और बस @model.Age कहते हैं। इस तरह आपको अपने दृश्य मॉडल का उपयोग कर रहे सभी विचारों में उस कोड को डुप्लिकेट करने की आवश्यकता नहीं है।

व्यूमोडेल के बारे में आपके प्रश्न का उत्तर यह है कि इसमें केवल तर्क होना चाहिए जिसका उपयोग "मॉडल" से जानकारी को सही ढंग से प्रस्तुत करने के लिए किया जाता है।

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

आशा है कि आपके प्रश्न का उत्तर दें।

अद्यतन

मैं एक अलग परियोजना बनाने और इसे करने के लिए कक्षाओं में जोड़ना होगा। फिर बस अपने वेबप्रोजेक्ट से एक संदर्भ जोड़ें और उन वर्गों को नियंत्रकों में कॉल करें।

मैं स्वचालित रूप से मेरे लिए बनाई गई निर्भरताओं को प्राप्त करने के लिए नियंत्रण कंटेनर का एक उलटा उपयोग करना शुरू कर दूंगा।

Autofac दोनों आपके लिए सेवाओं (शून्य-कॉन्फ़िगरेशन) की खोज कर सकते हैं और स्वयं को एमवीसी में इंजेक्ट कर सकते हैं।

अलग इंटरफेस पैटर्न निम्नलिखित परियोजनाओं को बनाने का पालन करें:

• YourProject.BusinessLayer < - यहाँ अपनी कक्षाओं जोड़े
• YourProject.BusinessLayer.Specification < - आप इंटरफेस जोड़े हैं जो आपके व्यापार परत को परिभाषित करता है यहाँ।
• YourProject.Mvc < - एमवीसी प्रोजेक्ट।

"विशिष्टता" परियोजना (केवल कुछ वर्गों और जरूरी नहीं कि पूरे कारोबार परत हो सकता है) यह आसान चीजों का परीक्षण करने और यह आसान कार्यान्वयन स्विच करने के लिए बनाने के लिए बनाने के लिए इस्तेमाल किया जा सकता। "पृथक इंटरफ़ेस पैटर्न" पर पढ़ें

Answer 2

मैं यह नहीं कह सकता कि मेरा दृष्टिकोण एक सर्वोत्तम अभ्यास है, लेकिन मैं किसी भी व्यावसायिक तर्क को एक अलग "सेवा" परत में रखना पसंद करता हूं।

मैं व्यूमोडेल का उपयोग केवल विशिष्ट दृश्य के लिए आवश्यक गुणों को संग्रहीत करने के लिए करता हूं। यदि व्यूमोडेल पर कोई भी तरीका है, तो संभवतः वे उस दृश्य से संबंधित संग्रह पुनर्प्राप्त करने की संभावना है।

मैं अपने नियंत्रकों को सत्यापन और पुनर्निर्देशन/यथासंभव दृश्यों को प्रदर्शित करने के लिए सीमित करने की कोशिश करके हल्के वजन रखता हूं।

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

उम्मीद है कि इससे मदद मिलती है। सौभाग्य।

Answer 3

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

उदाहरण के लिए:

आप एक सूची संपादक को लागू कर रहे हैं, आपके विचार मॉडल एक वस्तु मदों की एक सूची पकड़े होगा, और उजागर तरीकों आइटम जोड़ने और हटाने के लिए।

विकिपीडिया से:

ViewModel: ViewModel एक "दृश्य के मॉडल" है, जिसका अर्थ यह दृश्य भी है कि देखें और मॉडल के बीच बंधन डेटा में कार्य करता है के एक अमूर्त है। इसे के एक विशेष पहलू के रूप में देखा जा सकता है जो एक नियंत्रक (एमवीसी पैटर्न में) होगा जो डेटा बाइंडर/कनवर्टर के रूप में कार्य करता है जो मॉडल जानकारी को में बदलता है और दृश्य में मॉडल से आदेश पास करता है। ViewModel सार्वजनिक गुण, आदेश, और abstractions का खुलासा करता है।ViewModel को मॉडल में डेटा की वास्तविक स्थिति के विपरीत डेटा की एक वैचारिक स्थिति की तुलना में समझा गया है। [7]

Answer 4

आपका नियंत्रक यूओडब्लू को आपके व्यूमोडेल बनाने के लिए आवश्यक डेटा प्राप्त करने के लिए बुलाता है। आप अपने यूओडब्ल्यू

के 1 से अधिक तरीकों को कॉल कर सकते हैं तो आप अपने सभी आवश्यक डेटा को अपने व्यूमोडेल कन्स्ट्रक्टर में पास कर सकते हैं। (यूओ को देखने के लिए वास्तव में खराब लगता है)

यदि आपको यूओडब्लू आदि से बहुत सी विधियों को कॉल करने वाले आपके नियंत्रक पर कुछ जटिल 'तर्क' की आवश्यकता है, तो आपको केवल एक और भंडार या व्यावसायिक तर्क केवल परत बनाने पर विचार करना चाहिए सभी कड़ी मेहनत करता है और आप इसे अपने नियंत्रक से

SomeClass something = Uow.BLGoodName.DoSomeFancyStuff(params ..) 
ViewData.model = new ControllerActionViewModel(something); 
Return View();