क्या मुझे एमटीवीएम में अपने डेटा मॉडल के रूप में डीटीओ का उपयोग करना चाहिए?

Question

मैं वर्तमान में एमवीवीएम का उपयोग करने में अपना पहला वास्तविक प्रयास क्या कर रहा हूं और इस पर विभिन्न लेख पढ़ रहा हूं कि इसे कैसे कार्यान्वित किया जाए।

मेरे वर्तमान विचार डेटा डेटा ऑब्जेक्ट्स के रूप में प्रभावी रूप से मेरे डेटा मॉडल का उपयोग करना है, उन्हें क्रमबद्ध बनाना और उन्हें क्लाइंट और सर्वर दोनों पक्षों पर मौजूद होना है। यह एक तार्किक कदम की तरह लगता है कि दोनों ऑब्जेक्ट प्रकार वास्तव में केवल संपत्ति गेटर्स और सेटर्स के संग्रह हैं और बीच में एक और परत पूरी ओवरकिल की तरह दिखती है।

स्पष्ट रूप से INOTifyProperty के साथ समस्याएं होंगी, सर्वर सर्वर पर सही ढंग से काम नहीं कर रही है क्योंकि संचार करने के लिए कोई व्यूमोडल नहीं है, लेकिन जब तक हम सेवा परत में डेटा मॉडल से हमारे उचित डोमेन मॉडल ऑब्जेक्ट्स बनाने के बारे में सावधान रहें, सर्वर पक्ष पर डेटा मॉडल से निपट नहीं रहा मुझे नहीं लगता कि यह एक बड़ा मुद्दा होना चाहिए।

मुझे अपने पढ़ने में इस दृष्टिकोण के बारे में बहुत अधिक जानकारी नहीं मिली है, इसलिए मैं जानना चाहूंगा कि यह एक सुंदर मानक बात है, क्या यह एक बहु-बहुमत में एमवीवीएम करने का एक वास्तविक तरीका माना जाता है। स्तरीय पर्यावरण? अगर मुझे चीजों के बारे में पूरी तरह से गलत विचार मिल गया है तो अन्य दृष्टिकोणों पर विचार भी सराहना की जाएगी।

Answer 1

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

Answer 2

आप जो भी मॉडल सहज महसूस करते हैं उसका उपयोग कर सकते हैं, हां आपके सभी गुणों को INotifyPropertyChanged व्यवहार की आवश्यकता होगी। यह कैसे प्रभावी होगा सेवा परत पूरी तरह से आपके कार्यान्वयन के लिए नीचे है।

मुझे लगता है कि आप मानते हैं कि आप अपने डीटीओ से अपने विचार में बंधे हैं?

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

मैं निम्नलिखित तरीके से काम की स्थापना के लिए करते हैं:

// POCO object. Serializable. 
public class AddressDto 
{  
    public int Id { get; set; } 
    public string Street { get; set; }  
    public string City { get; set; }  
    public string Country { get; set; } 
} 

// IDataErrorInfo for validation. 
public class AddressViewModel : INotifyPropertyChanged, IDataErrorInfo 
{ 
    private readonly AddressDto addressDto; 

    public AddressViewModel(AddressDto addressDto) 
    { 
     this.addressDto = addressDto;  
    } 

    public int Id { /* get and set for property changed event and update dto */ } 
    public string Street { /* get and set for property changed event and update dto */ } 
    public string City { /* get and set for property changed event and update dto */ } 
    public string Country { /* get and set for property changed event and update dto */ } 
    ... 

    // IDataErrorInfo implementation 
} 

public class EditAddressViewModel : INotifyPropertyChanged 
{ 
    public AddressViewModel Address { /* get and set for property changed event */ } 
    public ICommand Save { /* setup command */ } 
    public ICommand Cancel { /* setup command */ } 

    private void Save() 
    { 
    } 

    private void Cancel() 
    { 
    } 
} 

आपका EditAddressView तो EditAddressViewModel करने के लिए बाध्य होगा। असल में नियम यह है कि आपका यूआई व्यवहार आपके व्यू मॉडल के संदर्भ में व्यक्त किया जाना चाहिए।

हां इसका मतलब अतिरिक्त काम है, कुछ चीजें हैं जो आप चीजों को सरल बनाने के लिए कर सकते हैं (कोड जनरेशन इत्यादि)। मैं वास्तव में एक पुस्तकालय पर काम कर रहा हूं जिसका उद्देश्य एक धाराप्रवाह एपीआई का उपयोग करके पूरी एमवीवीएम प्रक्रिया को सरल बनाना है।http://fluentviewmodel.codeplex.com/

Answer 3

पर इसे देखें, मैंने अपने व्यूमोडेल पर एक संपत्ति "मॉडल" रखने का निर्णय लिया है। मॉडल में ही मैं पहले से ही IPropertyNotifyChanged और IDataErrorInfo को लागू करता हूं। मेरे व्यू मॉडेल में मैं इस प्रकार गुणों को छोड़ देता हूं जहां कोड मॉडल के लिए "फॉल-थ्रू" होगा। इसके बजाए, दृश्य उन गुणों के लिए सीधे मॉडल पर बांधता है।

अधिक जटिल मामलों के लिए, जहां मुझे दृश्य में फिट करने के लिए मॉडल में डेटा समायोजित करना है, मैं इसे व्यूमोडेल में करता हूं। इसके अलावा, आदेश, आदि ViewModel में हैं। लेकिन मुझे व्यूमोडेल में बॉयलरप्लेट कोड रखने का कारण नहीं दिख रहा है, जो कि मेरे पास पहले से ही मॉडल में है।