2012-06-06 18 views
12

सबसे पहले, लंबा प्रश्न के लिए क्षमा करें, लेकिन मैं कुछ अंतर्निहित जानकारी देने के लिए किया है।डीटीओ पैटर्न + लेज़ी लोड हो रहा है + इकाई की रूपरेखा + ASP.Net MVC + ऑटो मैपर

हम एक आवेदन जो ASP.net MVC, JQuery टेम्पलेट, इकाई की रूपरेखा, WCF का उपयोग करता है पैदा कर रहे हैं और हम अपनी डोमेन परत के रूप में POCO का इस्तेमाल किया। हमारे आवेदन में, एएसपीनेट एमवीसी अनुप्रयोग के साथ डेटा का आदान-प्रदान करने के लिए एक डब्ल्यूसीएफ सेवा परत है और यह डब्ल्यूसीएफ से एमवीसी तक डाटा ट्रांसफर ऑब्जेक्ट्स (डीटीओ) का उपयोग करता है।

इसके अलावा, आवेदन AutoMapper का उपयोग करते समय हमारे WCF सेवा परत में डोमेन-से-DTOs परिवर्तित करके इकाई की रूपरेखा में लेज़ी लोड हो रहा है उपयोग करता है।

हमारे बैकएंड वास्तुकला के रूप में निम्नानुसार (WCF सेवाएँ -> प्रबंधक -> भंडार -> इकाई की रूपरेखा (POCO))

हमारे आवेदन, हम देखें मॉडल के रूप में हम एक और नहीं करना चाहते का उपयोग नहीं करते में एमवीसी अनुप्रयोग के लिए मैपिंग परत और हम केवल डीटीओ का उपयोग मॉडल के रूप में करते हैं।

आम तौर पर, हमारे पास ग्राहक, ग्राहक प्रकाश, आदि जैसे डोमेन के लिए सामान्य और लाइट डीटीओ होते हैं (लाइट ऑब्जेक्ट में सामान्य से कुछ गुण होते हैं)।

अब हमें डीटीओ के साथ कुछ कठिनाइयों का सामना करना पड़ रहा है क्योंकि हमारी डीटीओ संरचना अधिक जटिल हो रही है और जब हमें लगता है कि रखरखाव (डीटीओ की सामान्य श्रेणीबद्ध संरचना के साथ) हम प्रदर्शन खो देते हैं।

उदाहरण के लिए,

हम ग्राहक देखें पेज और हमारे डीटीओ पदानुक्रम के रूप में

public class CustomerViewDetailsDTO 
{ 
    public CustomerLiteDto Customer{get;set;} 
    public OrderLiteDto Order{get;set;} 
    public AddressLiteDto Address{get;set;} 
} 

इस प्रकार इस मामले में हम इस दृश्य के लिए OrderLiteDto के कुछ क्षेत्रों नहीं करना चाहती में है। लेकिन कुछ अन्य दृश्यों को उन क्षेत्रों की आवश्यकता होती है, ताकि यह सुनिश्चित करने के लिए कि हम उस संरचना का उपयोग करें।

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

मेरे सवाल:

  1. कोई तंत्र है कि हम प्रदर्शन में सुधार के लिए उपयोग कर सकते हैं, जबकि रख-रखाव पर विचार है?

  2. क्या उसी डीटीओ के लिए अधिक मानचित्र दृश्य आधारित मानचित्रण कार्यों के साथ ऑटोमैपर का उपयोग करना संभव है?

+1

लंबी? मेरी इच्छा है कि हर सवाल यह छोटा था :) –

उत्तर

11

पहले लेज़ी लोड हो रहा है के रूप में शायद का उपयोग नहीं करते यह एन चयन +1 समस्याओं या इसी तरह का परिणाम देगा।

एन + 1 डेटा एक्सेस एंटी-पैटर्न का चयन करें जहां डेटाबेस उप-स्थानिक तरीके से उपयोग किया जाता है।

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

टेम्पलेट्स के लिए jsRender उपयोग के रूप में यह JQuery टेम्पलेट्स की तुलना में काफी तेज है: Render Bemchmark और यहाँ है कि यह कैसे उपयोग करने के लिए के लिए एक अच्छा जानकारी है: Reducing JavaScript Code Using jsRender Templates in HTML5 Applications

आम तौर पर, हम इस तरह के ग्राहक के रूप में डोमेन के लिए सामान्य और लाइट DTOs है , ग्राहक लाइट, आदि (लाइट ऑब्जेक्ट में सामान्य से कुछ गुण हैं)।

आपका सामान्य डीटीओ के रूप में ViewModels या DTOs करने के लिए एक के लिए एक नक्शा नहीं हो सकता है शायद एक ViewModel है, और ViewModels अक्सर तर्क देखने से पीछे धकेल दिया होते हैं, या किसी उपयोगकर्ता के पर मॉडल के लिए वापस सूचना भेजे कराने में सहायता कर प्रतिक्रिया। डीटीओ का कोई व्यवहार नहीं है और उनका उद्देश्य एप्लिकेशन के स्तरों के बीच कॉल की संख्या को कम करना है।

कोई तंत्र है कि हम प्रदर्शन में सुधार करते हुए रख-रखाव पर विचार के लिए उपयोग कर सकते हैं है?

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

क्या उसी डीटीओ के लिए अधिक मानचित्र दृश्य आधारित मानचित्रण कार्यों के साथ ऑटोमैपर का उपयोग करना संभव है?

आप प्रत्येक मानचित्र को परिभाषित करने के लिए ऑटोमैपर का उपयोग कर सकते हैं, लेकिन सवाल यह है कि नक्शा कितना जटिल होगा। एक व्यू मॉडेल प्रति दृश्य का उपयोग करना और आपके नक्शे लिखना और बनाए रखना आसान होगा। मैं कहना चाहिए कि यह के रूप में डेटा का उपयोग कोड में Automapper उपयोग करने के लिए अनुशंसित नहीं है:

AutoMapper की

एक नकारात्मक पक्ष यह डोमेन से कि प्रक्षेपण है वस्तुओं अभी भी मजबूर करता पूरे डोमेन वस्तु पूछे और लोड किया जाना है।

स्रोत: Autoprojecting LINQ queries

आप विस्तार का एक सेट है कि डेटा का उपयोग कोड में अपने मानचित्रण तेजी लाने के लिए अब तक सीमित हैं का उपयोग कर सकते हैं: Stop using AutoMapper in your Data Access Code

सादर

+0

उत्तर के लिए धन्यवाद और यह वास्तव में सराहना करता है। कभी-कभी, आलसी लोडिंग को बंद करना एक हेज़ल है क्योंकि हमें आवश्यक जोड़ों को मैन्युअल रूप से शामिल करना होगा। मैं आपसे सहमत हूं कि एन + 1 अंक और आलसी लोडिंग देखभाल के साथ संभालना चाहिए। हम इकाई फ्रेमवर्क के साथ प्रदर्शन का विश्लेषण करने के लिए हमेशा एंटीटी प्रोफाइलर (http://efprof.com/) का उपयोग करते हैं। हम अपने दृढ़ता परत में ऑटो मैपर का उपयोग नहीं कर रहे हैं। असल में, मैं एक दृश्य मॉडल के साथ एक दृश्य मॉडल से सहमत हूं और हमारे मामले में यह एक पृष्ठ के लिए एक डीटीओ बन जाएगा जो अनुकूल नहीं है। – marvelTracker

+0

कोई समस्या नहीं है। हां, efprofiler सॉफ्टवेयर का एक बड़ा टुकड़ा है। यदि यह आवश्यक जानकारी थी तो कृपया इसे उत्तर के रूप में चिह्नित करें। –

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