2011-01-03 15 views
19

सबसे लंबे समय तक मैं अपने डोमेन मॉडल को मेरे डीटीओ में मैप करने के लिए ऑटोमैपर का उपयोग कर रहा हूं, साथ ही साथ मेरे डीटीओ को डोमेन मॉडल पर मैपिंग भी कर रहा हूं।डोमेन मॉडलों पर बाल संग्रह वाले डीटीओ मैपिंग के लिए डिज़ाइन पैटर्न

मैं अपने ओआरएम के लिए ईएफ 4 का उपयोग कर रहा हूं, और इस मानचित्रण में वास्तव में बदसूरत हो जाता है जब मॉडल मैप किए जाने वाले बच्चे संग्रह होते हैं जिन्हें जोड़ने/अपडेट/निकालने की आवश्यकता होती है। जैसे-जैसे मैं अपनी परियोजना के साथ आगे बढ़ता हूं, मैं इस समस्या में और अधिक से अधिक चल रहा हूं: ब्लॉग पोस्ट के लिए फोटो, ऑर्डर के लिए पैकेज इत्यादि।

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

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

+0

Automapper का उपयोग करते हुए अपने डोमेन मॉडल मैप करने के लिए संभवत: आपके उपयोग नहीं कर डोमेन प्रेरित डिजाइन का मतलब है। बस केह रहा हू। – jfar

+1

क्या मेरे लिए कुछ ऑटो-मैजिक मैपिंग समाधान का उपयोग करके इस मानचित्रण को साफ तरीके से संभालना चाहते हैं? क्या मुझे अपने डीटीओ से अपने डोमेन मॉडल को अपडेट करने के लिए पूरी तरह से सेवा बनाना चाहिए? – inolen

+0

@jfar आप कैसे समझते हैं? सबसे पहले, एक डोमेन मॉडल डीडीडी के समानार्थी नहीं है। यह लागू करना कि डोमेन मॉडल को मैप नहीं किया जाना चाहिए, इसे "डोमेन संचालित डिज़ाइन का उपयोग न करने" के रूप में बंद करना, और कोई और स्पष्टीकरण प्रदान करना बहुत उपयोगी नहीं लगता है, है ना? एक स्तरित वास्तुकला में डोमेन मॉडल के शीर्ष पर बैठे एक सेवा परत को ढूंढना असामान्य नहीं है। सेवा परत के लिए डोमेन, यूई और अन्य परतों से ट्रैनफर ऑब्जेक्ट के माध्यम से बात करना असामान्य नहीं है - इन परतों के बीच "चमकदार रेखा" रखने में मदद करना। – nerraga

उत्तर

3

आप इस कार्यक्षमता के लिए ऑटोमैपर के बजाय ValueInjecter का उपयोग करना चाह सकते हैं। इस प्रश्न को देखें जहां AutoMapper vs ValueInjecter दोनों के निर्माता वजन करते हैं। मैंने व्यक्तिगत रूप से वैल्यू इंजेक्टर का उपयोग नहीं किया है, लेकिन यह वह करने के लिए बनाया गया था जिसे आप करने की कोशिश कर रहे हैं।ऑटोमैपर फ़्लैटनिंग के लिए बेहतर है, लेकिन ऑटोमैपर के लेखक मानते हैं कि यह "अनफ्लैटिंग" के लिए एक अच्छा टूल नहीं है, जो आप करने की कोशिश कर रहे हैं।

1

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

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

+0

यह सुनकर अच्छा लगा कि मैं अकेला नहीं हूं। मैं अपने AutoMapper में मेरी ठोस भंडार को संदर्भित वास्तव में बुरा लग रहा है, फिर भी, मैं आईओसी का उपयोग कर सिर्फ उन इकाई परीक्षण योग्य है करने के लिए शुरू करने की इच्छा नहीं है (मैं आम तौर पर निर्माता पैरामीटर के रूप में खजाने लेने के लिए)। मैं कर सकता जटिल मामलों के लिए इन सेवा कक्षाएं सिर्फ DTOs वापस मर्ज करने के लिए बनाते हैं, और मुझे लगता है कि साधारण मामलों के लिए AutoMapper का उपयोग जारी रखने, लेकिन यह रूप में अच्छी तरह sortof कमजोर लग रहा है। मैं बोर्ड भर में उपयोग करने के लिए एक सतत डिजाइन पैटर्न खोजना चाहता हूं। – inolen

+0

यह परियोजना मैं अपनी दूसरी विधि उपयोग कर रहा है पर काम कर रहा हूँ की तरह लगता है, हम हालांकि जहां ऐसा लगता है कि हम अपने DTOs से मूल्यों में लोड करने से पहले सभी अलग संस्थाओं क्वेरी करने के लिए स्विच करना होगा एक बिंदु पर कर रहे हैं। मैं इसके खिलाफ हूं क्योंकि यह "गलत लगता है", मुझे अपडेट चलाने से पहले पूछताछ क्यों करनी चाहिए? मैं सोच रहा हूं कि आलसी लोडिंग का विस्तारित रूप मुझे डोमेन को सिग्नल करने देगा, जो मेरी संस्थाओं पर संपत्तियों को मेरे डीटीओ से सेट नहीं किया गया था और यदि आवश्यक हो तो उन्हें डीबी से लाया गया। मैं इसे टी 4 टेम्पलेट कर सकता था, लेकिन एक बार फिर ऐसा लगता है जैसे मैं माइक्रोसॉफ्ट के लिए एंटिटी फ्रेमवर्क लिख रहा हूं ... –

1

हाइबरनेट में एक झरना विकल्प जहां बच्चों के लिए किए गए अपडेट्स ..

मुझे लगता है कि NHibernate एक समान cascadeAll विकल्प है नहीं है।

0

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

हम NHibernate के साथ एक ही मुद्दा था और हम इस तरह इसे हल: डेटाबेस डीटीओ के आईडी का उपयोग कर से बाहर इकाई खींचने के लिए

  1. उपयोग ConstructWith।
  2. पूरे बच्चे संग्रह को साफ़ करने के लिए पहले मैप का उपयोग करें (सुनिश्चित करें कि बच्चे पर संदर्भ भी शून्य पर सेट हो जाएगा)।
  3. ऑटोमैपर स्वचालित रूप से नए संग्रह की प्रतिलिपि बनायेगा।

सौभाग्य से, एनएचबर्ननेट केवल परिवर्तन लागू करने के लिए पर्याप्त स्मार्ट था, मैं नहीं बता सकता कि क्या ईएफ समान है। यह एक सही समाधान नहीं है, लेकिन यह एक साधारण डोमेन मॉडल के लिए काम करता है।

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