क्यों दो वर्ग, मॉडल और डोमेन मॉडल देखें?

Question

मुझे पता है कि मॉडल मॉडल के रूप में डोमेन मॉडल का उपयोग करना बुरा हो सकता है। यदि मेरे डोमेन मॉडल में IsAdmin नाम की एक संपत्ति है और मेरे पास उपयोगकर्ताओं को बनाने के लिए एक नियंत्रक क्रिया बनाएं, तो कोई मेरा फॉर्म बदल सकता है और इसे एक ISAdmin = true फॉर्म मान पोस्ट करने के लिए प्राप्त कर सकता है, भले ही मैंने अपने दृश्य में ऐसे टेक्स्ट फ़ील्ड का पर्दाफाश न किया हो । अगर मैं मॉडल बाध्यकारी का उपयोग कर रहा हूं तो जब मैंने अपना डोमेन मॉडल किया, तो वह व्यक्ति अब एक व्यवस्थापक होगा। इसलिए समाधान केवल दृश्य मॉडल में आवश्यक गुणों को उजागर कर रहा है और मेरे डोमेन मॉडल ऑब्जेक्ट के लिए मेरे लौटने वाले दृश्य मॉडल ऑब्जेक्ट के प्रॉपर्टी वैल्यू को मैप करने के लिए ऑटोमैपर जैसे टूल का उपयोग कर रहा है। लेकिन मैंने पढ़ा कि क्लास पर बाइंड विशेषता का उपयोग मॉडल बाइंडर को निर्देश देने के लिए किया जा सकता है, जो गुणों को बांधना चाहिए और बांधना नहीं चाहिए। तो दो अलग-अलग वर्ग (डोमेन मॉडल और दृश्य मॉडल) बनाने का वास्तव में क्या कारण है जो आवश्यक रूप से एक ही चीज़ का प्रतिनिधित्व करते हैं और फिर उन्हें मानचित्रण में ओवरहेड लगाते हैं? क्या यह एक कोड संगठन मुद्दा है और यदि हां, तो मुझे कैसे फायदा हो रहा है?

संपादित

सबसे महत्वपूर्ण कारणों मैं एक दृश्य मॉडल कि डोमेन मॉडल से अलग है, के लिए का सामना करना पड़ा में से एक के प्रबंधन के लिए MVVM पैटर्न (मार्टिन Fowler के प्रधानमंत्री पैटर्न के आधार पर) को लागू करने की जरूरत है जटिल यूआई

Answer 1

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

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

Answer 2

कभी-कभी आपको डेटा को एक विशिष्ट तरीके से प्रदर्शित करने की आवश्यकता होती है (यानी, प्रारूप mm/dd/yyyy बनाम yyyy/mm/dd में दिनांक प्रदर्शित करना) और अक्सर इस संपत्ति को देखने में आसान बनाना आसान होता है और डोमेन मॉडल में नहीं, जहां आप अपने डीबी में एक कॉलम पर मैपिंग (या चाहिए) होगा।

Answer 3

व्यूमोडेल रखने का एक और अच्छा कारण डेटा के बड़े सेट पेजिंग कर रहा है। आप व्यक्ति को एक व्यक्ति (Person[]) देख सकते हैं लेकिन मेटाडेटा जैसे पृष्ठों की संख्या, वर्तमान पृष्ठ की संख्या, पृष्ठ का आकार Person कक्षा से संबंधित नहीं होगा।

इसलिए एक व्यक्ति सूची दृश्य मॉडल इस समस्या को हल करेगा।

Answer 4

एक व्यू मॉडेल केवल उन सदस्यों को रखता है जिन्हें दृश्य द्वारा आवश्यक है। उन्हें आमतौर पर अंतर्निहित डोमेन मॉडल के सरलीकरण या "फ़्लैटनिंग" के रूप में माना जा सकता है।इस तरह उनमें से

सोचें:

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

उदाहरण के लिए, मेरी ऑर्डर क्लास ग्राहक नामक एक सदस्य है जो composition एसोसिएशन है, यानी, मेरा ऑर्डर में ग्राहक है। इस ग्राहक ऑब्जेक्ट में फर्स्टनाम, लास्टनाम इत्यादि जैसे सदस्य हैं ... लेकिन मैं आदेश के "विवरण" दृश्य या ऑर्डर की सूची और उन ग्राहकों को कैसे रखूंगा जो उन्हें रखे?

ठीक है, एक व्यूमोडेल का उपयोग करके मेरे पास ऑर्डरलिस्ट इटिम व्यूमोडेल हो सकता है जिसमें ग्राहक नाम सदस्य है और मैं ग्राहक ऑब्जेक्ट से प्रथम नाम और अंतिम नाम के संयोजन को मैप कर सकता हूं। यह मैन्युअल रूप से किया जा सकता है, या अधिकतर Automapper या इसी तरह का उपयोग कर सकते हैं।

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

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

Answer 5

आप कि आपके domain model classes केवल internally उपयोग किया जाता है याद करने के लिए की जरूरत है; यानी, उन्हें क्लाइंट को कभी नहीं भेजा जाता है। यही है कि आपके सेवा मॉडल प्रकार (मॉडल प्रकार देखें) का उपयोग किया जाता है-वे उस डेटा का प्रतिनिधित्व करते हैं जो ग्राहक और आपकी सेवा के बीच आगे और आगे जा रहा है।