आईओसी

Question

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

public EntityContract AddEntity(EntityContract requestContract) 
{ 
    var entity = Mapper.Map<EntityContract, Entity>(requestContract); 

    var updatedEntity = Service.AddEntity(entity); 

    var responseContract = Mapper.Map<Entity, EntityContract>(updatedEntity); 

    return responseContract; 
} 

सेवा और मैपर गुण आईओसी कंटेनर के रूप में एकता के साथ निर्माता इंजेक्शन का उपयोग कर स्थापित कर रहे हैं: यहाँ क्या विधि नज़र आ सकते हैं।

public Entity AddEntity(Entity entity) 
{ 
    // Make changes to entity 

    Repository.Add(entity); 

    // Prepare return value 
} 

भंडार भी निर्माता इंजेक्शन का उपयोग कर सेट किया गया है:

कार्रवाई करते में, डोमेन सेवा इकाई में परिवर्तन तो तरह BREAK परिवर्तनों को लागू करने के लिए भंडार का उपयोग करता है बनाता है।

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

यदि मेरा लक्ष्य इकाई को अमान्य स्थिति में प्रवेश करने से रोकने के लिए है, तो क्या मुझे अपनी सेवा सेवा में इकाई को निष्क्रिय करना चाहिए ताकि यह सुनिश्चित किया जा सके कि सभी नियम मेरी डोमेन सेवा पर अनुरोध पारित करने से पहले संतुष्ट हैं? मैं ऐसा करने में संकोच करता हूं क्योंकि ऐसा लगता है कि मैं सेवा के मुखौटे में परिभाषित इन नियमों के साथ encapsulation तोड़ रहा हूँ।

डोमेन सेवाओं के लिए प्रतिनिधि पतली मुखौटा परत का उपयोग करने का कारण यह है कि हम अपने एपीआई में पाठ्यक्रम-अनाज वाले इंटरफेस का पर्दाफाश कर रहे हैं लेकिन जुर्माना वाली डोमेन सेवाओं की संरचना के माध्यम से पुन: उपयोग का समर्थन करते हैं। ध्यान में रखते हुए कि कई मुखौटा सेवाएं एक ही डोमेन सेवा विधि को कॉल कर सकती हैं, शायद इन नियमों को डोमेन सेवा में शामिल करना बेहतर होगा, इसलिए हम जानते हैं कि प्रत्येक उपयोग मान्य है। या मैं दोनों जगहों में मान्य होना चाहिए?

मैं संपत्ति सेटर्स में गार्ड भी डाल सकता हूं जो इकाई को किसी अमान्य स्थिति में रखने से अस्वीकार्य मानों को रोकता है। इसका मतलब यह होगा कि अमान्य मान को मैप करने का प्रयास करते समय ऑटोमैपर विफल हो जाएगा। हालांकि, जब कोई मान मैप नहीं किया जाता है तो यह मदद नहीं करता है।

मैं अभी भी यह सोच नहीं पा रहा हूं कि ये नियम इकाई के व्यवहार का हिस्सा हैं और यह निर्धारित करना कि वस्तु मान्य है या नहीं, इकाई के भीतर encapsulated किया जाना चाहिए। क्या यह गलत है?

तो सबसे पहले मुझे यह निर्धारित करने की आवश्यकता है कि मैं कब और कहां इन सत्यापन जांच करता हूं। तो मुझे यह पता लगाने की जरूरत है कि DI के साथ कैसे कार्यान्वित किया जाए ताकि निर्भरता को कम किया जा सके।

आप कौन से सुझाव प्रदान कर सकते हैं?

Answer 1

मैं DDD (इवांस) और साथ ही नीलसन के "नीले पुस्तक" पढ़ सकते हैं और कर रहा हूँ स्पष्ट नहीं सत्यापन करने के लिए क्या दृष्टिकोण मैं ले जाना चाहिए है।

ब्लू बुक किसी भिन्न कोण से समस्या का सामना करता है। मुझे लगता है कि 'सत्यापन' शब्द का उपयोग नहीं किया जाता है क्योंकि यह एक खतरनाक overgeneralization है। ऑब्जेक्ट इनवेरिएंट, सत्यापन के बारे में सोचने का एक बेहतर तरीका है। ऑब्जेक्ट्स (न केवल डीडीडी में) को अपने आंतरिक इनवेरिएंट को स्वयं लागू करना चाहिए। यह यूआई या सेवाओं या अनुबंध या मैपर या 'सत्यापन फ्रेमवर्क' या वस्तुओं के बाहर बाहरी कुछ भी नहीं है। Invariants आंतरिक रूप से लागू कर रहे हैं।आपको ये उत्तर उपयोगी हो सकते हैं: 1, 2, 3, 4।

मैं भी संपत्ति setters कि कभी गलत राज्य में इकाई लगाने से अस्वीकार्य मूल्यों को रोकने में गार्ड डाल सकता है। इसका मतलब यह होगा कि को अमान्य मान मैप करने का प्रयास करते समय ऑटोमैपर विफल हो जाएगा।

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

Answer 2

आप सत्यापन के दो प्रकार के होते हैं:

1. वस्तु स्थिरता: संस्थाओं की जिम्मेदारी है। संस्थाओं को आपको उन्हें अमान्य स्थिति में सेट करने की अनुमति नहीं देनी चाहिए, निर्भरताओं को लागू किया जाना चाहिए, मूल्य सीमा में होना चाहिए। आपको कक्षाओं के तरीकों और गुणों और रचनाकारों को अमान्य स्थिति की अनुमति न देने के लिए डिज़ाइन करना होगा।

2. व्यवसाय भूमिकाएं सत्यापन: इस प्रकार के सत्यापन के लिए सर्वर प्रसंस्करण की आवश्यकता होती है, जैसे आईडी उपलब्धता की जांच करना, विशिष्टता ईमेल करना और इसी तरह। सत्यापन के इन प्रकारों को दृढ़ता से पहले मान्यताओं या विनिर्देशों के रूप में सर्वर में संसाधित किया जाना चाहिए।