2009-11-11 15 views
26

मैं डब्ल्यूपीएफ के एमवीवीएम डिजाइन पैटर्न की जांच कर रहा हूं। लेकिन मुझे डेटा एसेस कोड कहां रखना है?एमवीवीएम डाटा एक्सेस लेयर कहां रखना है?

कुछ उदाहरणों में मैंने देखा है, डेटा एक्सेस सीधे व्यूमोडेल में किया जाता है। व्यूमोडेल में एसक्यूएल के लिए linq की तरह कुछ डालने के लिए यह अजीब लगता है? अन्य उदाहरणों में डेटा एक्सेस के लिए एक अलग परियोजना है, ऐसा लगता है कि ऐसा लगता है?

क्या यह कोई सामान्य दृष्टिकोण है? मुझे लगता है कि मैं यहाँ कुछ याद कर रहा हूँ!

धन्यवाद

+2

कभी-कभी नमूना कोड बिंदु को चित्रित करने के लिए लिखा जाता है। उत्पादन कोड लिखा जाना चाहिए ताकि यह रखरखाव और समझा जा सके। – Min

उत्तर

11

मैं एक और परत जोड़ना होगा, अनिवार्य रूप से क्या आप चाहते हैं एक डेटा कारखाना है। आप कक्षाओं का एक सेट बनाना चाहते हैं जो आपके लिए डेटाबेस में CRUD होगा और ViewModel पर स्वच्छ POCO ऑब्जेक्ट्स लौटाएगा।

Nerd Dinner पुस्तक पर देखने के लिए एक अच्छा उदाहरण होगा। इसमें एमवीसी एमवीवीएम नहीं है लेकिन पैटर्न बहुत समान हैं और जिस तरह से वे उस समाधान में डेटा तक पहुंचते हैं, वे अच्छे शुरुआती बिंदु होंगे।

उम्मीद है कि इससे मदद मिलती है।

+2

धन्यवाद। मुझे लगता है कि नेरड डिनर रिपोजिटरी पैटर्न का उपयोग करता है (जैसा कि क्रिस्टोफर द्वारा भी सुझाया गया है)। फ़ाइल संरचना के संदर्भ में मुझे लगता है कि मैं डेटा एक्सेस निर्देशिका में रिपोजिटरी क्लास और संबंधित मैपर को अलग कर दूंगा। अभी भी ऐसा लगता है कि यह एक बड़ा क्षेत्र है जो एमवीवीएम में काफी हद तक अनियमित हो जाता है। एक बार फिर धन्यवाद। –

+0

नेडरडिनर उदाहरण वास्तव में भंडार पैटर्न का एक अच्छा उदाहरण है। हालांकि वे विचारों में डोमेन मॉडल का पर्दाफाश करते हैं (यानी वे एमवीवीएम का उपयोग नहीं करते हैं), जिसे खराब अभ्यास माना जाता है। – Kristoffer

+0

@ लुकाज़, बेवकूफ रात्रिभोज में वे सीधे linq को sql विधियों के लिए कहते हैं। क्या यह ठीक है? मॉडल wol linqtosql उत्पन्न वर्ग हो जाएगा? –

5

MVVM मॉडल, देखें, और ViewModel के लिए खड़ा है। जो टुकड़ा आप गायब हैं वह मॉडल है, जहां आपका डेटा एक्सेस कोड रहता है।

ViewModel मॉडल लेता है और प्रदर्शन के लिए देखें यह प्रस्तुत करता है, तो आम तौर पर आप कुछ इस तरह होगा:

class PersonModel : IPerson 
{ 
    // data access stuff goes in here 
    public string Name { get; set; } 
} 

class PersonViewModel 
{ 
    IPerson _person; 

    public PersonViewModel(IPerson person) 
    { 
     _person = person; 
    } 

    public Name 
    { 
     get { return _person.Name; } 
     set { _person.Name = value; } 
    } 
} 

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

+1

इसे चुनें। –

+0

देखें http://jonas.follesoe.no/YouCardRevisitedImplementingTheViewModelPattern.aspx –

+0

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

10

डेटा एक्सेस दृश्य मॉडल में होना चाहिए, क्योंकि यह डोमेन मॉडल के दृश्य विशिष्ट (संभावित रूप से सरलीकृत) प्रतिनिधित्व के रूप में माना जाता है।

अपने मॉडल (पहले एम) में अपने व्यू मॉडल (एमवीवीएम में वीएम) को मैप करने के लिए किसी प्रकार के मैपर का उपयोग करें। आपके मॉडल में नई वस्तुएं फैक्ट्री पैटर्न का उपयोग करके बनाई जा सकती हैं। एक बार बनाया गया, आप उन्हें भंडार पैटर्न का उपयोग कर डेटाबेस में स्टोर कर सकते हैं। तब भंडार आपकी डेटा एक्सेस परत का प्रतिनिधित्व करेंगे। आपके भंडार में आप एन/आर मैपर जैसे NHibernate या Entity Framework का उपयोग कर सकते हैं।

संपादित करें:
मुझे लगता है कि GraemeF मॉडल में डेटा का उपयोग कोड डाल सुझाव देता है। यह नहीं एक अच्छा दृष्टिकोण है, क्योंकि इससे आपको अपने डोमेन मॉडल को अपडेट करने के लिए मजबूर किया जाएगा यदि आप उदा। ओरेकल या एक्सएमएल फाइलों के लिए एसक्यूएल सर्वर। डोमेन ऑब्जेक्ट्स को चिंता करने की ज़रूरत नहीं है कि वे कैसे बने रहते हैं। भंडार पैटर्न डोमेन को अपने दृढ़ता से अलग करता है।

+1

अच्छा बिंदु; बेशक आप इसे और अधिक ले जा सकते हैं। मेरा मुद्दा यह है कि डेटा एक्सेस कोड उस इंटरफेस के पीछे छिपा हुआ है और व्यूमोडेल में नहीं रहता है। – GraemeF

1

आपका व्यू मॉडेल एक पतली परत होनी चाहिए जो केवल दृश्य को देखे। अंगूठे का मेरा नियम: यदि इसे यूआई की प्रस्तुति के साथ करना है, तो यह व्यूमोडेल में है, अन्यथा यह मॉडल में होना चाहिए।

40

यहां बताया गया है कि मैं अपने MVVM डब्ल्यू/LINQ परियोजनाओं के आयोजन किया गया है:

मॉडल - मैं सिस्टम की स्थिति के रूप में मॉडल के बारे में सोच। यह डेटा के लिए एक इंटरफेस प्रदान करता है, और यह सिस्टम की स्थिति का ट्रैक रखता है। मॉडल को व्यूमोडेल या व्यू के बारे में पता नहीं है - यह सिर्फ अपने डेटा और विभिन्न घटनाओं को सार्वजनिक इंटरफ़ेस प्रदान करता है ताकि उपभोक्ताओं को (आमतौर पर व्यूमोडेल) पता चले कि राज्य कब बदल गया है।

ViewModel - ViewModel के आयोजन या सभी डेटा देखें द्वारा आवश्यक की संरचना, (जैसे कि एक डेटा ग्रिड के वर्तमान में चयनित पंक्ति के रूप में) को देखने की स्थिति का ट्रैक रखने, और कार्रवाई का जवाब देने के आरोप में है दृश्य पर (जैसे बटन धक्का)। यह जानता है कि को की आवश्यकता है, लेकिन यह वास्तव में दृश्य के बारे में नहीं जानता है।

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

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

डेटाएप क्लासेस - सी # में, ये बहुत सरल वर्ग हैं जो आपके मूल डेटा ऑब्जेक्ट्स को मॉडल करते हैं। जब आप LINQ क्वेरी का उपयोग करके कुछ चुनते हैं, तो आप आमतौर पर IEnumerable<T> या List<T> बनायेंगे जहां T आपकी डेटा ऑब्जेक्ट्स में से एक है। एक डेटा वस्तु का एक उदाहरण होगा:

public class Person 
{ 
    public string Name { get; set; } 
    public int Age { get; set; } 
} 

इस तरह की एक डिजाइन के बड़ा लाभ यह है कि यह वास्तव में अपनी चिंताओं को अलग करती है। सब कुछ एक विशेष नौकरी है, और यह (आमतौर पर) यह जानना बहुत आसान है कि किस तरह की चीज कहां जाती है।

नुकसान यह है कि यह छोटी परियोजनाओं के लिए अधिक हो सकता है। आप सार्वजनिक इंटरफेस के लिए बहुत सारे बुनियादी ढांचे का निर्माण करते हैं जो मूल रूप से कई परतों के माध्यम से एक ही इच्छा को पार करते हैं। तो, आप इस तरह के परिदृश्य के साथ समाप्त हो सकते हैं: [उपयोगकर्ता क्लिक सबमिट करते हैं, ViewModel AddNewPerson को मॉडल बताता है, मॉडल इस तरह के परिदृश्य के बजाय गेटवे को इंसर्टपर्सन को बताता है] [उपयोगकर्ता क्लिक सबमिट करें, ViewModel सीधे डेटाबेस में नया रिकॉर्ड जोड़ता है]।

उम्मीद है कि मदद करता है।

+7

क्या आप कृपया एमवीवीएम की अपनी व्याख्या का एक छोटा सा उदाहरण प्रदान कर सकते हैं क्योंकि अच्छे डीएएल समाधानों की खोज करते समय मैं हमेशा मृत सिरों तक पहुंच गया – WiiMaxx

2

WPF Application Framework (WAF) एक नमूना आवेदन से पता चलता है कि कैसे मॉडल-व्यू-ViewModel (MVVM) पैटर्न इकाई की रूपरेखा के साथ संयोजन में इस्तेमाल किया जा सकता शामिल हैं।

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