2010-11-12 14 views
5

मैं एक एएसपीएनटी एमवीसी एप्लीकेशन तैयार कर रहा हूं जो एक सेवा परत का उपयोग करता है। क्या होगा यदि हमारे पास ऐसी सेवा है जो किसी अन्य सेवा पर निर्भर करती है? के लिए, उदाहरण के लिए, मान लीजिए हम निम्नलिखित मॉडल है:सेवा परत परस्पर निर्भरता

class UserService : IUserService 
{ 
    //implementation requires IEmailService 
}  

ज़रूर, ठोस कार्यान्वयन EmailService UserService के निर्माता में इंजेक्ट किया जा सकता है लेकिन मेरी समझ में, एक सेवा परत यूआई और डोमेन मॉडल के बीच मध्यस्थता करना चाहिए, यह है एक मुखौटा की तरह। मैं एक और परत को इस तरह से परिभाषित करता हूं कि उपयोगकर्ता सेवा IUserModule और IEmailModule पर निर्भर करती है, इस तरह हम सेवाओं के बीच निर्भरता को कम कर सकते हैं, सेवाओं को निम्न परत (मेरे मामले मॉड्यूल परत में) पर निर्भर किया जा सकता है। क्या यह एक सही दृष्टिकोण है?

उत्तर

6

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

तो यदि आपके पास केवल एक तरह की सेवा है, जो मुझे लगता है कि दोनों जिम्मेदारियां शामिल हैं। परस्पर निर्भरता रखने के लिए पूरी तरह से मान्य है।

alt text

1

ज़रूर, ठोस कार्यान्वयन EmailService UserService के निर्माता में इंजेक्ट किया जा सकता है लेकिन मेरी समझ में, एक सेवा परत यूआई और डोमेन मॉडल

खैर के बीच मध्यस्थता चाहिए, यह के बीच एक अनुबंध है पक्षों के लिए, जरूरी नहीं कि यूआई और डोमेन मॉडल, लेकिन आमतौर पर।

यह एक मुखौटा की तरह है।

हां, एक अच्छी सेवा में प्रदर्शन के लिए लेखांकन एक अच्छा मुखौटा भी है।

इस तरह हम निचले स्तर (मेरे मामले मॉड्यूल परत में) पर निर्भर सेवाओं के बीच निर्भरता तोड़ सकते हैं। क्या यह एक सही दृष्टिकोण है?

मॉड्यूल आपके लिए क्या मायने रखता है? क्या IEmailService आपके लिए एक सेवा या मॉड्यूल है? आपकी सेवा के लिए आपके मामले में फेकाडे बनाने के लिए यह सही लगता है। लेकिन आप अपने सिस्टम और आपके इरादे और अपनी वास्तुशिल्प चुनौतियों/प्राथमिकताओं के बारे में कुछ जानकारी प्रदान करते हैं।

+0

फाल्कन, मॉड्यूल में व्यवसाय नियम और भंडार परत के साथ बातचीत शामिल है। – Markus

-4

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

+0

"निर्भरता इंजेक्शन कुछ ऐसा है जो आपको टालना चाहिए क्योंकि यह लचीलापन के भ्रम के लिए युग्मन और जटिलता को बढ़ाता है।" क्या? – kyoryu

+0

मिच, क्या आप जानते हैं कि निर्भरता इंजेक्शन या एमवीसी क्या है और इसका उपयोग कैसे करें? – Falcon

+0

-1: कुछ "शोध" करने के लिए सलाह देने से पहले कुछ शोध करें। आप जवाब वास्तविकता से 180 डिग्री का सामना कर रहे हैं। –

संबंधित मुद्दे