सेवा परत

Question

के लिए डीआई (कन्स्ट्रक्टर इंजेक्शन) के लिए डिज़ाइनिंग रिपॉजिटरीज IoC और कन्स्ट्रक्टर इंजेक्शन का उपयोग करने की कोशिश कर रहा हूं, मैं एक एमवीसी 3 ऐप बना रहा हूं। मेरे डेटाबेस में (अब तक) लगभग 50 टेबल हैं। मैं अपने डीएसी कोड के लिए ईएफ 4 (डब्ल्यू/पीओसीओ टी 4 टेम्पलेट) का उपयोग कर रहा हूं। मैं भंडार पैटर्न का उपयोग कर रहा हूं, और प्रत्येक तालिका का अपना भंडार है। मेरी सेवा परत में मेरी सेवा कक्षाओं को इन/भंडारों को इंजेक्शन दिया जाता है।

समस्या: मेरी सेवा कक्षाएं उन्हें आवश्यक भंडारों की संख्या में बढ़ रही हैं। कुछ मामलों में, मैं 10 भंडारों तक पहुंच रहा हूं, और यह गंध शुरू हो रहा है।

क्या रिपोजिटरी और सेवा कक्षाओं को डिजाइन करने के लिए कोई आम दृष्टिकोण है कि सेवाओं को इतनी सारी रिपॉजिटरीज़ की आवश्यकता नहीं है?

यहाँ मेरे विचार कर रहे हैं, मैं तो बस यकीन नहीं है जो एक सही है कर रहा हूँ:

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

2) यह एक संकेत है कि मुझे अपने भंडारों (तालिकाओं) के आधार पर समूहों में अपनी सेवाओं को तोड़ने पर विचार करना चाहिए। इसके साथ समस्या यह है कि मेरी कुछ सेवा विधियां आम कार्यान्वयन साझा करती हैं, और कक्षाओं में इन्हें तोड़ने से मेरी निर्भरता जटिल हो सकती है।

3) यह एक संकेत है कि मुझे नहीं पता कि मैं क्या कर रहा हूं, और कुछ मौलिक रूप से गलत है कि मैं देखने में भी सक्षम नहीं हूं।

अद्यतन: कैसे मैं EF4 और खजाने को लागू कर रहा हूँ की एक विचार के लिए, codeplex पर this sample app की जाँच (मैं version 1 प्रयुक्त)। हालांकि, वहां कुछ टिप्पणियों को देखते हुए (और यहां), ऐसा लगता है कि मुझे यह सुनिश्चित करने के लिए थोड़ा और पढ़ने की ज़रूरत है कि यह वह मार्ग है जिसे मैं लेना चाहता हूं - ऐसा लगता है कि ऐसा नहीं हो सकता है।

Answer 1

Chandermani is right कि आपकी कुछ तालिका कोर डोमेन कक्षाएं नहीं हो सकती हैं। इसका मतलब है कि आप एक ही प्रकार की मूल इकाई के संदर्भ में उस डेटा को कभी भी खोज नहीं पाएंगे। उन मामलों में आप उन्हें पूर्ण-उग्र संस्थाओं के बजाय "जटिल प्रकार" के रूप में संदर्भित कर सकते हैं, और ईएफ अभी भी आपकी देखभाल करेगा।

मैं भंडार पैटर्न का उपयोग कर रहा है, और प्रत्येक मेज अपने स्वयं के भंडार

है मुझे आशा है कि आप स्क्रैच से इन खुद लिख नहीं कर रहे हैं।

ईएफ 4.1 पहले से ही the Repository Pattern (DbSet) लागू करता है, और the Unit of Work pattern (DbContext)। पुराने संस्करण भी करते हैं, हालांकि DbContext टेम्पलेट को उन गुणों को IDbSet पर बदलकर एक साफ नकली कार्यान्वयन प्रदान करने के लिए आसानी से tweaked किया जा सकता है।

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

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

मेरी सेवा परत में मेरी सेवा कक्षाएं इन/इन भंडारों को इंजेक्शन दी गई हैं।

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

Answer 2

यदि आप DDD Aggregate Root पैटर्न देखते हैं और इस परिप्रेक्ष्य में आपको डेटा देखने का प्रयास करते हैं तो आपको पता चलेगा कि तालिका में से कई में स्वतंत्र अस्तित्व नहीं है। उनका डेटा केवल उनके माता-पिता के संदर्भ में मान्य है। उन पर अधिकांश कार्यों के लिए आपको माता-पिता को भी प्राप्त करने की आवश्यकता होती है। यदि आप ऐसी तालिकाओं को समूहित कर सकते हैं और मूल इकाई \ repository अन्य सभी बाल भंडार को हटाया जा सकता है। माता-पिता को जोड़ने की जटिलता जो अब तक आप अपनी व्यावसायिक परत में कर रहे हैं (मान लीजिए कि आप स्वतंत्र रेपो का उपयोग करके माता-पिता और बच्चे को पुनः प्राप्त कर रहे हैं) को डीएएल

सेवा इंटरफ़ेस को रीफैक्टर करना भी एक व्यवहार्य विकल्प है, और किसी भी सामान्य कार्यक्षमता को बेस क्लास में स्थानांतरित किया जा सकता है और \ या स्वयं को आपकी सेवा के रूप में परिभाषित किया जा सकता है, जो आपकी सभी मौजूदा सेवाओं (0 ए 30 बनाम ए है)

Answer 3

@ कंधर्मिनी की कुल जड़ों के बारे में एक अच्छी बात है। रेपॉजिटरीज़ नहीं होना चाहिए, आवश्यक तालिकाओं में 1: 1 मैपिंग होना चाहिए।

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

Answer 4

क्या आपकी सेवाएं सभी रिपॉजिटरीज को लिख रही हैं? मुझे लगता है कि मेरी सेवाएं रिपॉजिटरीज़ के साथ बहुत करीबी हैं, कि वे सीआरयूडी संचालन के आसपास व्यापार तर्क प्रदान करते हैं जो भंडार का पर्दाफाश करता है।