डब्ल्यूसीएफ - डोमेन ऑब्जेक्ट्स और IExtensibleDataObject

Question

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

वर्तमान में हम एक्सएमएल WS से एक WCF/वस्तु आधारित मॉडल में जाने पर विचार कर रहे हैं और विभिन्न दृष्टिकोण के साथ प्रयोग किया गया है। उनमें से एक में सीधे तारों पर डोमेन ऑब्जेक्ट्स/एग्रीगेट्स को स्थानांतरित करना शामिल है, संभवतः उन पर डेटाकंट्रैक्ट विशेषताओं का आविष्कार करना।

डेटामेम्बर पर ऑर्डर प्रॉपर्टी का उपयोग करके IExtensibleDataObject और डेटाकंट्रैक्ट का उपयोग करके, हमें सरल संपत्ति संस्करण समस्याओं से निपटने में सक्षम होना चाहिए (याद रखें, हम सभी ग्राहकों को नियंत्रित करते हैं और आसानी से उन्हें अपडेट कर सकते हैं)।

मैं सुनवाई है कि हम तार पर समर्पित, स्थानांतरण-केवल डाटा ट्रांसफर ऑब्जेक्ट (DTOs) का उपयोग करना चाहिए रखने के लिए।

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

तो - हम क्यों DTOs उपयोग करने के लिए की जरूरत है?

Answer 1

मेरे अनुभव DTOs में के लिए सबसे उपयोगी होते हैं:

1. कड़ाई से परिभाषित करने के लिए क्या तार पर भेजा जाएगा और एक प्रकार विशेष रूप से उस परिभाषा के लिए समर्पित कर रहे हैं।
2. भविष्य के परिवर्तनों से आपके शेष एप्लिकेशन, क्लाइंट और सर्वर को अलग करना।
3. गैर-नेट सिस्टम के साथ इंटरऑपरेबिलिटी। डीटीओ निश्चित रूप से एक आवश्यकता नहीं है, लेकिन वे "सुरक्षित" प्रकारों को डिजाइन करना आसान बनाते हैं।

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

Answer 2

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

यदि कोई मौका है कि आप हमेशा ग्राहकों के नियंत्रण में नहीं रहेंगे तो मैं निश्चित रूप से डीटीओ की सिफारिश करता हूं, क्योंकि जैसे ही आप किसी अन्य के क्लाइंट एप्लिकेशन के साथ अपनी डोमेन ऑब्जेक्ट्स साझा करते हैं, आप किसी अन्य व्यक्ति के लिए अपने आंतरिक को जोड़ना शुरू करते हैं देव चक्र

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

अंत में, यदि आप क्लाइंट अनुप्रयोग के लिए बहुत कुछ है यह भी DTOs उपयोग करने के लिए के रूप में आप उसे आसानी से versionable सेवा के साथ सुरक्षित हैं यह फायदेमंद हो सकता है।