प्याज वास्तुकला: क्या हमें अपनी डोमेन इकाइयों में डेटा एनोटेशन की अनुमति देनी चाहिए?

Question

मैं अपने एएसपी.नेट एमवीसी अनुप्रयोग में प्याज वास्तुकला को लागू करने के लिए देख रहा हूं। मैं डोमेन इकाइयों से व्यू मॉडल को अलग करने की आवश्यकता को समझता हूं, हालांकि मैं खुद को अनावश्यक कोड लिख रहा हूं। अनावश्यक कोड है क्योंकि मेरे व्यू मॉडल और डोमेन इकाइयां बिल्कुल अपवाद के साथ समान दिखती हैं कि मेरे दृश्य मॉडल में [सीरियलज़ेबल] डेटा एनोटेशन है। मुझे इन मॉडलों को क्रमबद्ध करने की आवश्यकता है क्योंकि मैं एएसपी.नेट सत्र राज्य का उपयोग कर रहा हूं जिसमें राज्य सर्वर को वस्तुओं को क्रमबद्ध करने की आवश्यकता है।

मैं व्यक्तिगत रूप से महसूस डोमेन संस्थाओं serializable नहीं होना चाहिए, क्योंकि यह तो एक विशेष तकनीक पर निर्भर हो जाएगा। हालांकि, मैं अनावश्यक कोड से कैसे बच सकता हूं?

मुझे यह जोड़ना चाहिए कि मेरी सेवा विधियां इन धारावाहिक डेटा मॉडल पर निर्भर हैं।

Answer 1

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

बिंदु अपने उद्देश्य पर ध्यान केंद्रित परतों इसे mix'em और (समय में) बनाने के लिए बहुत आसान है क्योंकि मिट्टी का बड़ा गेंद रखने के लिए है।

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

आप कुछ एप्लिकेशन और अधिक जटिल यानी बनने के लिए विकसित नहीं होगा रहे हैं यह सिर्फ डेटा संरचना जोड़तोड़ हो जाएगा तो आप सभी प्रयोजनों के लिए उन्हें इस्तेमाल करने के लिए एक मॉडल हो सकता है। असल में आप कोनों को काट सकते हैं और सब कुछ के लिए 'व्यापार' मॉडल का उपयोग कर सकते हैं। Abstractions और अन्य सामान की कोई ज़रूरत नहीं है।

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

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

Answer 2

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

Answer 3

मैं प्रति डेटा एनोटेशन [Serializable] पर कॉल नहीं करता, क्योंकि यह कोर .Net प्लेटफार्म (mscorlib.dll) का हिस्सा है। डेटा एनोटेशन specific attributes को एएसपी.Net या इकाई फ्रेमवर्क में डेटा सत्यापन और अन्य संचालन करने के लिए उपयोग किया जाता है।

एक इकाई [Serializable] होना चाहिए? शायद नहीं, लेकिन मुझे नहीं लगता कि यह विशेषता बाहरी, वेब- या दृढ़ता-उन्मुख पुस्तकालयों से आने वाले अन्य विशेषताओं के रूप में आपकी डोमेन परत पर "मिलाव" के रूप में है। यह आपको किसी विशेष तृतीय-पक्ष ढांचे से नहीं जोड़ता है।

संपूर्ण "अनावश्यक कोड" समस्या आपके द्वारा बनाई जा रही प्रणाली के प्रकार पर आईएमओ निर्भर करती है।एक वास्तविक डीडीडी आवेदन में, डोमेन इकाइयों और दृश्य मॉडल के बीच डुप्लिकेशंस संभवतः सभी चमकदार नहीं होंगे, और एक अलग प्रस्तुति मॉडल के लाभ आम तौर पर लागत से अधिक होंगे। उस विषय पर एक अच्छा लेख: Is Layering Worth The Mapping?