रिपोजिटरी पैटर्न और एकाधिक संबंधित कोर इकाइयों या व्यावसायिक वस्तुओं - एक भंडार या अधिक?

Question

मैं रिपोजिटरी पैटर्न को कार्यान्वित करने के लिए देख रहा हूं (चूंकि मैं इसके साथ आया था, वैसे भी 9 0% इसका कार्यान्वयन था), और एक डिजाइन प्रश्न में आया है - जहां मेरे पास दो या दो से अधिक कोर बिजनेस ऑब्जेक्ट्स हैं (उदाहरण के लिए, व्यवसाय और एक सीआरएम ऐप में संपर्क करें), बीओ का दृढ़ता से संबंधित या संबंधित नहीं हो सकता है।

इस स्थिति में, क्या मुझे एक भंडार (उदाहरण के लिए CrmRepository, .addBusiness(), .addContact() et al), या एकाधिक रिपॉजिटरीज़ (BusinessRepository, ContactRepository प्रत्येक के साथ अपने .add(), .delete को लागू करना चाहिए() और अन्य)।

इस स्थिति में सबसे अच्छा अभ्यास क्या है?

अंतर्निहित डीएएल ईएफ 4 है।

सादर

मू

Answer 1

हम अपने काम में हाल ही में सोच का एक बहुत कर रहे हैं और कुछ लेख है कि हम कल्पना और एक सुसंगत तरीके से हमारे खजाने डिजाइन में मदद मिली बारे में जाना।

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

आपके प्रश्न में आपकी जानकारी के साथ ऐसा लगता है कि एक व्यवसाय एक समग्र रूट होगा और इस प्रकार एक इकाई प्रकार होगा और इसके अपने भंडार की आवश्यकता होगी। चूंकि संपर्क स्वतंत्र रूप से जीवित रह सकता है क्योंकि यह भी एक समग्र रूट हो सकता है। दोनों ऑब्जेक्ट्स एक दूसरे के संदर्भ हो सकते हैं और किसी संपर्क से व्यवसाय को लोड करने के लिए एक रिपोजिटरी का उपयोग कर सकते हैं या अपने संबंधित भंडार के माध्यम से व्यवसाय से संपर्क लोड कर सकते हैं।

मैं हाल ही में बहुत पढ़ रहा हूं इसलिए मुझे उम्मीद है कि मैंने अपनी विचार प्रक्रिया में कुछ समझ लिया है।

कुछ लिंक

Aggregate Root

Entities, Value Objects, Aggregates and Roots

Answer 2

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

तरीकों तो मेरी IReposity होगा:

T FindByKey<T>(int key); 
IEnumerable<T> FindAll(); 
T FindBy<T>(System.Linq.Expressions.Expression<Func<T, bool>> expression); 
void Update<T>(entity); 

फिर, अपने दर्शन के आधार पर आप भंडार वर्ग के आसपास पारित कर सकते हैं और इसे सीधे क्वेरी, या अपने भंडार कार्यान्वयन अमूर्त बनाने के लिए और बल इसे करने के लिए फायदा नहीं है इस तरह, एक स्पष्ट भंडार द्वारा समझाया जा:

CrmRepository : Repository 
{ 
    FindByCustomerId(int customerId) 
    { return FindByKey<Customer>(customerId);} 
}