एमवीसी 3 में, क्या मेरे पास अलग-अलग "संपादन" मॉडल बनाम "प्रदर्शन" मॉडल होना चाहिए?

Question

एमवीसी 3 के साथ, क्या मुझे अपने व्यू मॉडलों को डिज़ाइन करना चाहिए जैसे कि दृश्य (डिस्प्लेमोडेल) के लिए बाध्य है, और एक जिसे नियंत्रक (एडिटमोडेल) पर वापस पोस्ट किया गया है?

स्पष्टीकरण के लिए, मैं डेटा मॉडल बनाम मॉडल के बारे में नहीं पूछ रहा हूं - मुझे पता है कि मेरे विचार/नियंत्रकों को डेटा/डोमेन मॉडल में बाध्य करना अच्छा नहीं है।

न ही मैं एक मॉडल को दो अलग-अलग विचारों में साझा करने के बारे में पूछ रहा हूं, एक दृश्य जिसे डेटा प्रदर्शित करने के लिए उपयोग किया जाता है, और डेटा को संपादित करने के लिए उपयोग किया जाने वाला एक और दृश्य।

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

दूसरे शब्दों में, अगर यह मेरे विचार है:

@model MyApp.Models.CustomerModel 

की तरह मेरे नियंत्रक कार्रवाई दिखना चाहिए:

public ActionResult Index(CustomerModel model) 

या:

public ActionResult Index(CustomerEditModel model) 

एक बिंदु पर, हम थे उत्तरार्द्ध (अलग) कर रहे हैं। लेकिन हाल ही में, हमने पूर्व (साझा) करना शुरू कर दिया है।

इस परिवर्तन का कारण था क्योंकि:

1. MVC3 विनीत सत्यापन की सहायता से

   , अगर मैं सत्यापन के लिए अपने मॉडल पर DataAnnotations उपयोग कर रहा हूँ, यह दोनों मॉडल में की जरूरत है अगर वे प्रदर्शन पर अलग होती है (क्लाइंट-साइड सत्यापन को मैप करने के लिए मॉडल, और सर्वर-साइड सत्यापन के लिए संपादन मॉडल पर)।

2. हमारे आवेदन परिपक्व होने के बाद, हमने महसूस किया कि हमारे प्रदर्शन मॉडल में मौजूद चुनिंदा सूचियों के अपवाद के साथ, हमारे प्रदर्शन और संपादन मॉडल 95% समान थे। अब हम इन्हें shared class पर ले जा चुके हैं और इन्हें अब दृश्य के माध्यम से पास कर रहे हैं।

लेकिन मैं कुछ अन्य विचार विमर्श उस दृश्य/नियंत्रक के लिए साझा मॉडल होने एक बुरा विचार है, और चिंताओं में से है कि it violates जुदाई होने की ओर इशारा करते देखा है।

क्या कोई मुझे इन दो दृष्टिकोणों के लिए व्यापारिक समझने में मदद कर सकता है?

Answer 1

मैंने इसके लिए और इसके खिलाफ पूरी तरह से अच्छे तर्क देखे हैं, यह केवल आपके आवेदन के लिए सबसे अच्छा काम करता है। लागू नहीं किया जा सकता है कि सभी दृष्टिकोण फिट बैठता है!

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

Answer 2

यदि गुण प्रदर्शित करने के लिए गुण समान हैं और दृश्य मॉडल संपादित करते हैं तो मुझे अलग-अलग कक्षाएं रखने का कोई कारण नहीं दिखता है।

Answer 3

मुझे लगता है कि आप पाएंगे कि यह हिट या याद आती है कोई बात नहीं क्या रास्ता तुम जाओ, लेकिन यदि आप सबसे आसान रख-रखाव के रास्ते ले जा सकते हैं तो आप उस करना चाहिए। मेरे अनुभव में, एक मॉडल रखने के लिए स्पष्ट रूप से बनाए रखना बहुत आसान है, लेकिन ऐसा लगता है कि हमेशा कुछ व्यावसायिक निर्णय होता है जो मुझे मॉडल को विभाजित करने के लिए मजबूर करता है। यदि आप उस 9 5% में हैं तो मुझे लगता है कि आप वास्तव में अच्छे आकार में हैं।आपके मॉडल से संबंधित रखरखाव परिप्रेक्ष्य से आपका आवेदन, बनाए रखना आसान होगा। जब कोई परिवर्तन आता है, तो अधिकांश भाग के लिए आपके पास उस परिवर्तन को करने के लिए एक स्थान होता है। जिस मुद्दे को मैं हमेशा चलाने के लिए प्रतीत होता हूं वह कई मॉडलों में व्यावसायिक परिवर्तनों को स्केल कर रहा है। मुद्दों को कॉपी/पेस्ट करें, या बस कुछ संपत्ति के बारे में भूल जाना, हमेशा बहु-मॉडल मुद्दे के कारण मुझे चोट लगती है।

Answer 4

हमने महसूस किया कि हमारे प्रदर्शन मॉडल में मौजूद चुनिंदा सूचियों के अपवाद के साथ हमारे प्रदर्शन और संपादन मॉडल 95% समान थे। अब हमने को साझा कक्षा में ले जाया है और अब इन्हें दृश्य के माध्यम से पास कर रहे हैं।

क्या वे डेटा और संचालन में या केवल डेटा में 95% समान हैं? याद रखें कि कक्षाएं डेटा और व्यवहार को समाहित करती हैं।

यदि वे गुणों में 9 5% समान हैं लेकिन पूरी तरह से अलग-अलग संचालन हैं तो आपको उन्हें दो वर्गों में विभाजित करने से लाभ हो सकता है। या आप शायद नहीं कर सकते हैं :)

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

Answer 5

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

बेस व्यू मॉडल से इनहेरिट यदि आपको डेटा एनोटेशन पर भरोसा नहीं करना चाहिए या अपने मॉडल सेव पर धाराप्रवाह एपीआई का उपयोग करना है।

एक महान लिंक (कुछ असंबंधित लेकिन ऑटो नक्शा अच्छा है)

संपादित (खेद किसी और ने पहले इस नीचे मैं सिर्फ एहसास हुआ तैनात) http://lostechies.com/jimmybogard/2009/06/30/how-we-do-mvc-view-models/

इसके अलावा

ASP.net MVC - One ViewModel per View or per Action?

आप (IMHO) आमतौर पर साझा दृश्य मॉडल की बजाय अपने विधि विशिष्ट VieWModel पर बाध्यकारी होना चाहिए। आप गायब संपत्तियों के जाल में फंस सकते हैं, आदि, लेकिन यह आपके लिए भी ठीक काम कर सकता है।

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

Answer 6

मैं rich.okelly's answer से सहमत हूं कि कोई सही दृष्टिकोण नहीं है।

हालांकि, मुझे एक मॉडल का उपयोग करने के साथ कुछ चिंताएं हैं।

दृश्यों की एक चयन योग्य सूची प्रदर्शित करने के लिए दृश्य को अनदेखी गुणों के बिना हमेशा एक मॉडल का उपयोग करना होगा। मॉडल को ऑब्जेक्ट्स की सूची और साथ ही संपत्ति को उपयोगकर्ता द्वारा चुने गए पोस्ट किए गए मूल्य को स्वीकार करने की आवश्यकता होगी। ये अनियंत्रित गुण कोड अव्यवस्था और ओवरहेड की एक छोटी राशि जोड़ते हैं। (इस के चारों ओर एक तरीका यह है कि मॉडल में केवल चयनित आईडी है और एचटीएमएल हेल्पर्स सूचियां बनाने के लिए हैं।)

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

इन चिंताओं का यह मतलब नहीं है कि दो मॉडल अच्छे हैं और एक मॉडल खराब है, लेकिन डिजाइन चुनते समय उन्हें विचार किया जाना चाहिए।