आवेदन की कौन सी परत में डीटीओ कार्यान्वयन

Question

हाल ही में मैं डीटीओ के बारे में बहुत कुछ सुन रहा हूं और वे कितने उपयोगी हैं लेकिन मुझे एएसपी.NET संदर्भ में इसका उपयोग करने का एक अच्छा उदाहरण नहीं मिल रहा है।

मान लीजिए कि मैं तीन स्तरीय संरचना का उपयोग करते हैं:

1. डेटा परत (इकाई की रूपरेखा का प्रयोग करके)
2. व्यापार लेयर (WCF सेवा)
3. प्रस्तुति परत (MVC 4.0 वेब अनुप्रयोग)

मुझे ईएफ कर्मचारी ऑब्जेक्ट से कर्मचारी कर्मचारी टीओसीओ में कहां से परिवर्तित करना चाहिए?

मान लें कि मैं डेटा एक्सेस परत में रूपांतरण करता हूं लेकिन डब्ल्यूसीएफ सेवा में क्या होता है? इसके बाद इसे किसी अन्य DataMember ऑब्जेक्ट में परिवर्तित किया जाना चाहिए और जब यह यूआई परत (एमवीसी वेब ऐप) के लिए मिलता है तो इसे तीसरे बार मॉडल में परिवर्तित किया जाना चाहिए? अगर कोई मुझे इस के लिए इसे साफ़ कर सकता है तो मैं इसकी सराहना करता हूं

Answer 1

इसी तरह की स्थिति में मैं डीटीओ को कोर में डालता था जो तीनों के लिए जाना जाता है। तो आपके पास

 
    Core 
     | 
------------ 
|  | | 
DAL BL PL 

प्रत्येक परत Core.Dto.Employee के साथ संचालित हो सकती है। प्रत्येक परत अपने एपीआई में बाहरी रूप से Core.Dto.Employee का खुलासा करती है। लेकिन आंतरिक रूप से प्रत्येक परत Core.Dto.Employee को बदल/अनुकूलित कर सकती है, उदा। आप डेटाबेस EF.Employee से पढ़ते हैं और बाद में इसे Core.Dto.Employee में परिवर्तित करते हैं। परिवर्तन परत की सीमा से निहित है।

यदि आपके पास परतों में एक ही चीज़ का प्रतिनिधित्व करने के लिए कई अलग-अलग मॉडल हैं, उदाहरण के लिए पीएल PL.Employee चाहता है और डीएएल EF.Employee पर काम करता है, तो आप एक गड़बड़ी के साथ समाप्त हो जाएंगे।

Answer 2

https://stackoverflow.com/a/6310507/1771365 पर एक नज़र डालें, क्योंकि मेरे पास टिप्पणियां जोड़ने के लिए पर्याप्त प्रतिष्ठा नहीं है।

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

यदि आप अपनी सभी परतों के बीच डीटीओ का उपयोग करने की योजना बना रहे हैं तो एक क्रॉस कटिंग प्रोजेक्ट बनाएं जिसका आप संदर्भ दे सकते हैं।

Answer 3

एक दृष्टिकोण जो मैं विशेष रूप से शौकीन हूं, आपके व्यापार परत में डीटीओ रूपांतरण के लिए है।

परिदृश्य: आपका प्रेजेंटेशन लेयर आपके बिजनेस लेयर को डीटीओ पास करने पर कॉल करता है। आप कुछ तर्क & सत्यापन करते हैं, फिर डीटीओ को एक इकाई में कनवर्ट करें और इसे अपने डेटा एक्सेस लेयर पर भेजें।

यानी यूआई -> बस। परत (इकाई में कनवर्ट करें) -> डेटा लेयर

मुझे इस दृष्टिकोण को पसंद है क्योंकि मुझे लगता है कि डेटा लेयर में कोई रूपांतरण तर्क नहीं होना चाहिए और आवश्यकतानुसार इकाइयों को प्राप्त करना और उन्हें संभालना चाहिए। यह एक और कारण यह प्रभावी है कि अब आप डेटा लेयर पर भेजने से पहले रूपांतरण प्रक्रिया के दौरान विशिष्ट व्यावसायिक नियम/सत्यापन तर्क परिभाषित कर सकते हैं। यहां एक पुराना MSDN article है, लेकिन इसमें एक समान दृष्टिकोण समझाते हुए कुछ शानदार विवरण हैं।

Answer 4

कोई रूपांतरण नहीं होना चाहिए। आप सिर्फ डीटीओ के रूप में पोको ऑब्जेक्ट्स का उपयोग करेंगे।

ईएफ पोको के साथ काम करता है और उन्हें डब्ल्यूसीएफ द्वारा क्रमबद्ध किया जा सकता है।

उन्हें सभी परियोजनाओं द्वारा संदर्भित एक असेंबली में परिभाषित किया जाना चाहिए।

एएसपी.नेट एमवीसी में आप पोको-डीटीओ का उपयोग करके व्यूमोडेल पर मैप करेंगे।

Answer 5

आपकी सेवा परत डीटीओ का खुलासा करती है। इसका मतलब है कि सेवा परत में आप डेटा अनुबंध को परिभाषित करते हैं क्योंकि आप उन्हें बाहरी दुनिया के संपर्क में रखना चाहते हैं। ज्यादातर मामलों में वे उन इकाइयों को चकित करते हैं जिनके पास आपके डेटाबेस इकाइयों के समान संरचना नहीं होती है।

व्यापार/डेटा परत का उपयोग करने और डीटीओ का निर्माण करने के लिए यह आपकी सेवा परत की ज़िम्मेदारी है जिसे आप बाहरी दुनिया में प्रकट करते हैं।

आपके व्यापार और डेटा परत में आप जो भी उपयोग करते हैं वह आर्किटेक्चर पर निर्भर करता है। आपके पास एक डोमेन मॉडल हो सकता है जिसे पहले कोड के साथ मैप किया गया हो। उस स्थिति में, सेवा परत डोमेन अनुबंधों को डेटा अनुबंध (डीटीओ) में मैप करती है। यदि आपके पास डोमेन मॉडल (एनीमिक मॉडल) नहीं है, तो आप डेटाबेस को सीधे अपने डीटीओ पर मैप कर सकते हैं।

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

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

अन्य टिप्पणी:

• अपने डेटाबेस संस्थाओं को बेनकाब न करें।
• व्यवसाय परत में परिवर्तित न करें, क्योंकि यह व्यवसाय तर्क नहीं है।

Answer 6

मैं साझा ऐसे प्रयोजनों के लिए नाम की एक परियोजना का उपयोग करें, spesifically सभी परतों के साथ साझा करने के लिए वस्तु। नाम के बावजूद, यह सभी परतों द्वारा दिखाई देना चाहिए।