डोमेन तर्क बनाम डेटा सत्यापन

Question

मैं मार्क सीमैन द्वारा नेट में निर्भरता इंजेक्शन पढ़ने और आनंद लेने में व्यस्त हूं।

सटीक संदर्भ की व्याख्या करना मेरे लिए काफी मुश्किल है, इसलिए यदि आप पुस्तक से परिचित हैं तो कृपया केवल इस प्रश्न से परेशान रहें।

मेरा प्रश्न अध्याय 2 पृष्ठ 49 में दो उत्पाद वर्गों के साथ करना है। डोमेन परत में से एक और डेटा एक्सेस परत में से एक है। यह समझाया गया है कि डेटा एक्सेस लेयर में उत्पाद वर्ग लिंक से एंटिटी विज़ार्ड द्वारा बनाया गया था।

मैं लिंक से एसक्यूएल के साथ काम कर रहा हूं, और मैं लिंग मॉडल से एसक्यूएल विशेषताओं के साथ अपने मॉडल वर्ग को सजाने सकता हूं, ताकि मेरे पास दूसरी कक्षा न हो। जैसे

[Table(Name="Customers")] 
public class Customer 
{ 
    [Column(IsPrimaryKey=true)] 
    public string CustomerID; 
    [Column] 
    public string City; 
} 

हालांकि मैं इस मिश्रण है चिंताओं लग रहा है और कहीं भी होगी प्रभाव एसक्यूएल डेटा का उपयोग परत को कसकर जोड़ी Linq के लिए अपने डोमेन परत में। क्या आप इस बात से सहमत हैं?

मान लीजिए कि मैं डोमेन और डेटा एक्सेस परत के लिए दो 'ग्राहक' कक्षाएं बनाता हूं। मान लें कि शहर एक आवश्यक क्षेत्र है। सहेजते समय, इस नियम की जांच की जानी चाहिए। क्या यह डोमेन परत या डेटा एक्सेस परत, या दोनों में किया जाना चाहिए?

धन्यवाद, Daryn

Answer 1

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

हम क्या करते हैं, लिंक-टू-एसक्यूएल इकाइयों को डीएएल में मौजूद होने दें, और फिर हमने डीएएल में कक्षाओं को मैपिंग करने के लिए एल 2 एस इकाइयों को डोमेन इकाइयों में परिवर्तित कर दिया है, और इसके विपरीत। और यह ठीक है, क्योंकि डीएएल वास्तव में आपका ओआरएम है, और इसका काम का हिस्सा यह मैपिंग करना है।

मैं कहूंगा कि अगर एक व्यापार नियम के रूप में शहर की आवश्यकता है, तो यह व्यवसाय तर्क है और व्यवसाय तर्क परत में व्यवसाय नियम के रूप में संबंधित है। वहाँ सत्यापन सत्यापन पैकेज हैं जो इस मुद्दे के साथ मदद कर सकते हैं।

Answer 2

हालांकि मुझे लगता है कि यह चिंताएं मिश्रण कर रहा है और यह असल में मेरी डोमेन परत को लिंक से SQL डेटा एक्सेस लेयर में जोड़ देगा। क्या आप इस बात से सहमत हैं?

हाँ, यह होगा। एंटीटी फ्रेमवर्क (कोड पहले) और निबर्ननेट दोनों अलग मैपिंग कक्षाओं का उपयोग कर सकते हैं जो आपके मॉडल को निर्भरता के बिना OR/M पर साफ कर देगा।

एक साइड नोट: डोमेन मॉडल में गुणों (डीडीडी में) के लिए सार्वजनिक सेटर्स नहीं होना चाहिए। चूंकि यह मॉडल मॉडल के बाहर मॉडल तर्क को प्रभावी ढंग से स्थानांतरित करता है।

मान लीजिए कि मैं डोमेन और डेटा एक्सेस परत के लिए दो 'ग्राहक' कक्षाएं बनाता हूं। मान लें कि शहर एक आवश्यक क्षेत्र है। सहेजते समय, इस नियम की जांच की जानी चाहिए। क्या यह डोमेन परत या डेटा एक्सेस परत, या दोनों में किया जाना चाहिए?

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

उदाहरण:

public class ArticleRepository 
{ 
    public void Save(Article article) 
    { 
     // Article is already in a correct state 
     // (thanks to no public setters) 

     var dbEntity = new ArticleEntity(); 
     Mapper.Map(article, dbEntity); 
     _dbContext.Save(dbEntity); 
    } 
}