क्या यह अच्छा विचार है कि ViewModel को बिल्कुल मॉडल के समान जोड़ें

Question

मेरे समाधान में निम्नलिखित परतें हैं:

1. App.Domain
2. App.Service
3. App.Core (शायद आप इसे एक App.DataLayer कहते हैं)
4. App.Web

सॉफ्टवेयर डिजाइन पैटर्न मेरा सवाल नहीं है, मैं मॉडल में निम्नलिखित है Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

मैं इस मॉडल का उपयोग दृश्य पर करना चाहता हूं (उदाहरण के लिए होम पेज) और मैं उपयोग करना चाहता हूं Id, Name & Value, इसलिए यदि मैं ViewModel बनाना चाहता हूं, तो मैं निम्नलिखित जोड़ूंगा:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

तो, क्या यह अच्छा विचार है? या सिर्फ के Fooबजाय का उपयोग करें FooViewModel?

Comments

मुझे यकीन नहीं है कि मैं यह समझता हूं। नहीं है Modelआम तौर पर करने के लिए पारित कर दिया View? क्यों वास्तव में आप के क्षेत्र पुन: बनाने की जरूरत है Modelमें View? अगर चिंताओं की जुदाई का एक लक्ष्य है MVC, किन परिस्थितियों में एक के साथ एक ही बात करने के लिए चाहते हो जाएगा के तहत Modelऔर View? यदि ViewModelदोनों, यही वजह है कि विस्तार / रचना दोनों से नहीं Modelऔर View?

— null

कृपया मेरी टिप्पणी @ svidgen के जवाब पर पढ़ें

— मेहदी देहगानी

मेरे पास एक संबंधित मुद्दा है - जहां मॉडल (और डेटाबेस में) पर सत्यापन (आवश्यक विशेषता) राज्य में कुछ मान दर्ज किए जाने चाहिए - लेकिन विचारों में, उन मूल्यों की आवश्यकता नहीं है - इसलिए मुझे कुछ क्षेत्रों से कॉपी करने के लिए मजबूर किया जाता है मॉडल सीधे मॉडल को देखते हैं - सीधे मॉडल को संदर्भित करने के बजाय। हालांकि प्रतिबिंब पर यह शायद ठीक है और वास्तव में DRY का उल्लंघन नहीं करता है क्योंकि वे विभिन्न उद्देश्यों के लिए हैं (वैसे भी बुरी तरह से नहीं)।

— निको सेप

Answer 1

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

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

यदि आपके दृश्य का "फ़ंक्शन" अंतर्निहित डोमेन मॉडल को प्रकट करने के लिए कड़ाई से है, तो उन प्रश्नों को ध्यान में रखते हुए, हाँ, ऐसा लगता है जैसे यह DRY नियम का उल्लंघन करता है।

_{यह भी ध्यान में रखते हुए, एक दृश्य को उजागर करना जो मॉडल परिवर्तनों के साथ अधिक स्वाभाविक रूप से बदलता है, कुछ भाषाओं में सदस्य विशेषताओं और प्रतिबिंब के साथ भी पूरा किया जा सकता है। (या चतुराई के अन्य कारनामों के माध्यम से कम पुनरावृत्ति के साथ ... लेकिन, "चतुराई" अक्सर पुनरावृत्ति को सही ठहराने में विफल हो जाती है जो आपको बख्श देती है।)}

Comments

अच्छे उल्लेख किए गए नोट्स (इसके लिए वोट करें), जैसा कि मैंने पिछले उत्तर पर टिप्पणी के रूप में कहा था, मैं सामान्य उद्देश्य, इमेजिंग के बारे में बात कर रहा हूं, हो सकता है कि कुछ दिनों बाद, मैंने नए क्षेत्र / संपत्ति को जोड़ने का फैसला किया Foo, इसलिए यदि मैं FooViewModel के रूप में उपयोग करता हूं भी, ग्राहक को नई संपत्ति भी मिलेगी, तो इस बारे में क्या होगा अगर यह नया कुछ सुरक्षा क्षेत्र था, (शायद अनुमति के लिए सही / गलत, या ऐसा कुछ), मुझे क्या करना चाहिए?

— मेहदी देघानी 17

@mehdi आपको इस बारे में अधिक विशिष्ट होना चाहिए कि आप किस क्षेत्र को जोड़ने के बारे में सोच रहे हैं और आपको क्यों लगता है कि यह दृश्य में है या नहीं। या सामान्य तौर पर, क्या चिंता है।

— svidgen

@mehdi स्पष्ट होना, यदि आप अंतिम उपयोगकर्ताओं को सुरक्षा मूल्य बदलने के बारे में चिंतित हैं, तो आपके डोमेन को उपयोगकर्ताओं को उन चीज़ों को सहेजने की अनुमति नहीं देनी चाहिए जिन्हें वे सहेजने के लिए अधिकृत नहीं हैं

— svidgen

हम ViewModels का उपयोग क्यों कर रहे हैं? कुछ कारण हैं, जैसा कि हम जानते हैं, उनमें से एक सुरक्षा के लिए है, उदाहरण के लिए, User edit formहमें IsAdminइस क्षेत्र को सुरक्षित रखने के लिए क्लाइंट को फ़ील्ड पास करने की आवश्यकता नहीं है , इसलिए यह वही है जिसके बारे में मुझे चिंता है। मेरी खराब इंग्लिश के लिए माफ़ कीजिये।

— मेहदी देहगानी

दूसरा रास्ता रखो, मुझे लगता है कि मूल प्रश्न एक पूर्ण प्रश्न है। जिस प्रश्न को आप यहां टिप्पणियों में जानने की कोशिश कर रहे हैं वह एक और पूर्ण प्रश्न है। और टिप्पणियाँ अच्छी, गुणवत्ता के उत्तर पाने का अच्छा तरीका नहीं हैं।

— svidgen

Answer 2

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

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

मैं एक FooViewModel के रूप में आपके विचार मॉडल के बारे में नहीं सोचूंगा, मैं इस बारे में सोचूंगा कि क्या दृश्य प्रदर्शित किया जाना चाहिए। यदि यह सिर्फ एक फू प्रदर्शित करता है, तो दृश्य मॉडल में एक गुण, एक फू शामिल है।

यकीन नहीं होता अगर मैंने स्पष्ट रूप से समझाया। यदि नहीं, तो मुझे बताएं और जब मैं जाग रहा हूँ तो मैं इसे पुनः प्रयास करूँगा!

Answer 3

मैं कहूंगा कि FooViewModelइस तरह से उपयोग करना DRY प्रिंसिपल का उल्लंघन करता है। जब आपको बदलाव करने की आवश्यकता होती है तो Fooआपको भी इसमें बदलाव करना होगा FooViewModel। मुझे लगता है कि आप केवल Fooअपने विचार के लिए मॉडल के रूप में उपयोग करना बेहतर होगा । अगर आप फू की चीजों और कुछ अन्य चीजों को प्रदर्शित करना चाहते हैं तो मैं एक दृश्य मॉडल पर विचार करूंगा। उदाहरण के लिए, मान लें कि आपको Fooऔर से भी कुछ जानकारी प्रदान करने की आवश्यकता है Bar।

Comments

कृपया मुझे बताएं, अगर मैंने एक और फील्ड / प्रॉपर्टी को जोड़ने का फैसला किया है Foo, इसलिए क्योंकि मैंने FooViewModel के रूप में भी उपयोग किया है, इसलिए मुझे इस नए क्षेत्र को भी देखना होगा, मुझे लगता है कि यह वास्तव में अच्छा सौदा नहीं है, आप क्या सोचते हैं ?

— मेहदी देहघानी

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

— शून्य_देव

क्या हुआ अगर वह जोड़ा गया क्षेत्र एक सुरक्षा क्षेत्र था, जैसे कि true/falseअनुमति के लिए कुछ मूल्य या ऐसा कुछ।

— मेहदी देघानी

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

— ग्राहम

ऐसा लगता है कि यह बड़े पैमाने पर असाइनमेंट हमलों के लिए खुला होगा

— जेम्स