डब्ल्यूसीएफ डेटा अनुबंध और एनम्स का साझाकरण

Question

वर्तमान में हमारे पास एक डब्ल्यूसीएफ सेवा है जो गणनाओं के लिए अपने डेटाकंट्रैक्ट्स के साथ स्थापित की गई है। इसके बाद हमारे पास डेटाकंट्रैक्ट एनम्स और हमारे व्यापार परत में उपलब्ध सामान्य एनम्स के बीच मैपिंग परत है। क्लाइंट एंड पर एक ही बात होती है - क्लाइंट एनम और डेटा अनुबंध एनम

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

इस पर लोगों के विचार क्या हैं?

Answer 1

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

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

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

Answer 2

मैं सेवा स्तर पर अलग डेटा अनुबंध enum रखने के लिए जाना होगा जो संस्करण संगतता पीओवी से बीएल enum के लिए नक्शे। यह भविष्य में बीएल से एनम मूल्यों को बदलने के बावजूद भविष्य में समान सेवा enum मानों और व्याख्या को रखने की अनुमति देगा। उदाहरण के लिए, आप सेवा और व्यावसायिक स्तर दोनों पर 4-5 समान मूल्यों (0, 1, 2, 3, 4) से शुरू कर सकते हैं। भविष्य में, आपने फ्लैग आधारित व्याख्या के लिए व्यवसाय enum को संशोधित करने का निर्णय लिया - इसलिए अलग-अलग सेवा enum होने से उन मानों को नए व्यवसाय enum मानों पर मैप करने की अनुमति मिल जाएगी (उम्मीद है कि उसी व्याख्या में उस स्तर पर उपलब्ध होगा) - परीक्षा 3 के लिए अब बिजनेस एनम में 8 तक मैप किया गया।

Answer 3

मैं वर्तमान में एक ही स्थिति में हूं। एक समाधान है कि एक और पतली परत है जिसे आप ServiceManager पर कॉल कर सकते हैं। इस परत में विधियां डेटा अनुबंध एम्स स्वीकार करती हैं, फिर यह बीएल विधियों को कॉल करने पर डेटा अनुबंध एनम प्रकार को बीएल एनम प्रकार में परिवर्तित करती है।

लेकिन मैंने फैसला किया है कि मेरा समाधान डेटा अनुबंध enums को निकालना है और केवल स्ट्रिंग स्थिरांक का उपयोग करना है।

यदि आपके पास बेहतर समाधान है तो कृपया साझा करें।