एमवीसी देखें मॉडल में डोमेन मॉडल का उपयोग

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

उदाहरण

लिए

public class LoginDomainModel 
{ 
    public string Email { get; set; } 
    public string Password { get; set; } 
    public string DisplayName { get; set; } 
    public long UserTypeID { get; set; }  
    public virtual UserType UserType { get; set; } 
} 
public class UserTypeDomainModel 
{ 
    public UserType() 
    { 
     this.Logins = new List<Login>(); 
    } 
    public long UserTypeID { get; set; } 
    public string UserType { get; set; } 
    public string Description { get; set; } 
    public virtual ICollection<Login> Logins { get; set; } 
} 

public class LoginViewModel 
{ 
    public string Email { get; set; } 
    public long UserTypeID {get; set;} 

    //Right here 
    public List<UserTypeDomainModel> UserTypesSelectList {get; set;} 
}

स्रोत

2013-02-23 Preston

सभी महान उत्तरों, सभी को धन्यवाद। – Preston

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

मैं कभी दृश्य की ज़रूरतों के लिए थोड़ा सा डोमेन मॉडल संशोधित नहीं कर सकता। मेरी परियोजनाओं में से 95% + में, यह वह परिस्थिति है जिसे मैं स्वयं में पाता हूं। जिस क्षण आप दृश्य के लिए डोमेन को प्रदूषित करते हैं, आप रखरखाव के सिरदर्द को पेश करते हैं।

स्रोत

2013-02-23 20:47:22

जब तक आपके डोमेन इकाइयां अपडेट नहीं होतीं और आपका दृश्य अभी तक नहीं हुआ है। फिर आपको नए आवश्यक फ़ील्ड के साथ सिरदर्द मिलता है जो इंटरफ़ेस में प्रस्तुत नहीं होते हैं। मुझे लगता है कि प्रत्येक के लिए, यह सिर्फ इस बात पर निर्भर करता है कि आपके डोमेन मॉडल में कितनी बार परिवर्तन हो सकता है या हो सकता है। –

@ ब्रैड क्रिस्टी: 9 5% परियोजनाओं में मैपिंग परत के साथ एक दृश्य मॉडल और डोमेन मॉडल अलग है (ऑटोमैपर अच्छा है)। 5% परियोजनाओं के लिए (छोटे, सरल वाले ... अक्सर 1 व्यक्ति वाले) जो अधिक है। –

संभवतः सुरक्षा प्रभाव हैं। मुझे लगता है कि व्यू/व्यूमोडेल में डोमेन मॉडल इकाइयों का उपयोग करने से संभावना बढ़ जाती है कि आप "ओवरपोस्टिंग" हमलों के रूप में सुरक्षा भेद्यताएं पेश करेंगे (http://odetocode.com/blogs/scott/archive/2012/03 भी देखें /11/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx)। मैं यह भी मानता हूं कि डोमेन इकाइयों का उपयोग सीधे/व्यूमोडेल में "एनीमिक डोमेन मॉडल" एंटी-पैटर्न (http://www.martinfowler.com/bliki/AnemicDomainModel.html) का संकेत है। मैं व्यू/व्यूमोडेल में "वैल्यू ऑब्जेक्ट्स" का उपयोग करूंगा, लेकिन संस्थाएं नहीं। – Nathan

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

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

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

मुझे केवल पढ़ने के लिए, अनबाउंड मूल्यों (संभवतः आपके मामले में उपयोगकर्ता प्रकारों की सूची, के लिए अलग दृश्य मॉडल बनाने की पूर्ण आवश्यकता नहीं दिखाई देती है, हालांकि public virtual ICollection<Login> Logins इसे अस्वीकार कर सकता है)।

वैकल्पिक रूप से, आप डोमेन मॉडल को UI- उन्मुख अमूर्तता (उदा। IEnumerable<SelectListItem>) पर प्रोजेक्ट करना चाहते हैं। आप विभिन्न इनपुट तंत्र के लिए SelectListItems का उपयोग कर सकते हैं, इसलिए आप स्वयं को किसी विशेष UI व्यवहार से नहीं जोड़ रहे हैं।

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

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

स्रोत

2013-02-23 21:03:11

यह "डोमेन मॉडल" से आपका क्या मतलब है इस पर निर्भर करता है। क्या आपका मतलब ईएफ इकाइयां हैं? या आप व्यापार परत वस्तुओं का मतलब है?

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

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

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

स्रोत

2013-02-23 21:03:48

मैं ईएफ इकाइयों का जिक्र कर रहा था। – Preston

@ प्रेस्टन - तो यह आपका डेटा मॉडल है, न कि आपका डोमेन मॉडल। और ऊपर मेरी सलाह अभी भी लागू होती है –

एमवीसी देखें मॉडल में डोमेन मॉडल का उपयोग

उत्तर

संबंधित मुद्दे