डब्ल्यूसीएफ डाटाकंट्रैक्ट्स और अंतर्निहित डेटा संरचनाएं

Question

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

अभी मेरे पास विभिन्न स्तरों पर संस्थाएं हैं: डेटा एक्सेस, व्यापार और अनुबंध। मेरे पास कनवर्टर्स हैं जो डाटाएप से बिजनेस और बिजनेस टू कॉन्ट्रैक्ट और इसके विपरीत इकाइयों को मैप कर सकते हैं। उनको कार्यान्वित करना और बनाए रखना समय लेने वाला और बहुत कठिन है। इसके संबंध में सर्वोत्तम प्रथाएं क्या हैं?

यदि मैं एनएच/एम जैसे एनएच/एम का उपयोग कर रहा था जैसे कि एनएचबीरनेट या एंटिटी फ्रेमवर्क क्या मुझे सीधे ओआरएम से इकाइयों को उजागर करना चाहिए या क्या मैं उन्हें वैसे ही सारण कर सकता हूं जैसा मैं अब कर रहा हूं?

अग्रिम धन्यवाद।

Answer 1

आम तौर पर, मुझे लगता है कि एक सर्वोत्तम प्रथाओं के दृष्टिकोण से, आपको डेटा अनुबंधों के रूप में अपनी व्यावसायिक वस्तुओं की संरचना का खुलासा नहीं करना चाहिए, बल्कि "डेटा अनुबंध-विशिष्ट" वर्गों को परिभाषित करना और व्यवसाय को अनुबंध में परिवर्तित करना चाहिए। इसके लिए अतिरिक्त काम की आवश्यकता हो सकती है, लेकिन चिंताओं को अलग करने और परिवर्तन दृष्टिकोण से सुरक्षा से अतिरिक्त काम शायद इसके लायक है।

Microsoft patterns & practices "Service Factory Modeling Edition" इस को लागू करता है, और यह भी स्वत: जनरेट व्यापार < => अनुबंध कनवर्टर वर्गों के लिए टूलींग प्रदान करता है - यह एक उत्कृष्ट वी.एस. ऐड-इन है, और भी WCF के लिए माइक्रोसॉफ्ट के सर्वोत्तम प्रथाओं का प्रतिनिधित्व करता है।

Answer 2

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

जिस क्षण आप इस तरह की इकाइयों का पर्दाफाश करते हैं ताकि वे तार पार कर सकें, फिर वे दो उद्देश्यों की सेवा कर रहे हैं। यह ओवरकिल की तरह प्रतीत हो सकता है, लेकिन यह चीजों को क्लीनर और पारदर्शी रखता है ... जो एक सरल डिजाइन के लिए पैदा होता है।

Answer 3

बस उपरोक्त उत्तरों में जोड़ने के लिए: ऑब्जेक्ट जो webservice का खुलासा करता है उसे डेटा ट्रांसफर ऑब्जेक्ट (डीटीओ) कहा जाता है। अपने बिजनेस एंटिटी ऑब्जेक्ट (बीईओ) को मैप करने के लिए डीटीओ होने के कारण यह आपके वेबसाइकिल और वास्तविक कार्यान्वयन/तर्क के बीच वेब-सेवा के पीछे मौजूद अलगाव के कारण अच्छा है।

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

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


//Data transfer object 
[DataContract(Name="Person")] //<-- this is what makes the WSDL look nice and clean 
class PersonDTO 
{ 
    [DataMember(Name = "Name", Order = 0)] 
    public string Name{ get; set; } 
    [DataMember(Name = "Age", Order = 1)] 
    public int Age{ get; set; } 
} 

Answer 4

कुछ भी विचार करने के लिए, मैं जुदाई के साथ सहमत हैं, लेकिन यह आम तौर पर व्यापार इकाई के लिए डीटीओ से डेटा कॉपी करने के लिए अग्रणी करने के लिए "अनुवादक" या कुछ इस तरह के कोड को हवाएँ। यह वह जगह है जहां ऑटोमैपर (http://automapper.org/) जैसी लाइब्रेरी वास्तविक काम में आती है और अनुवाद परत लिखने की आवश्यकता को दूर करती है।