2012-02-08 11 views
5

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

मैं वर्तमान में मेरे Wolfie समाधान में तीन परियोजनाओं है:

  • Wolfie.Core - डेटा का उपयोग कोड होता है, संदर्भ कोर - व्यावसायिक संस्थाओं
  • Wolfie.Data शामिल हैं।
  • Wolfie.Web - एक नॅन्सी वेबसाइट होगी।

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

डेटा में सभी रिपोजिटरी कक्षाओं में इंटरफेस हैं ताकि भंडारों को परीक्षण के लिए मजाक किया जा सके।

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

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

जो मैं लक्ष्य कर रहा हूं वह एक वास्तुकला है जहां मेरा मूल आवेदन स्वतंत्र है डेटा और वेब परत दोनों के।

मुझे उम्मीद है कि मैंने कुछ समझ लिया है और मैं कुछ उपयोगी उत्तरों की प्रतीक्षा कर रहा हूं।

+0

ऐसा लगता है कि आपको पहले ही जवाब मिल चुके हैं। तकनीकी कार्यान्वयन से व्यवसाय कोर तर्क को अलग करने के लिए आप बिल्कुल सही हैं। यह लगभग लगता है जैसे आप जेफरी पालेर्मो के ब्लॉग में वर्णित प्याज वास्तुकला से परिचित हैं और एएसपी.नेट एमवीसी इन एक्शन बुक श्रृंखला में उनके और अन्य लोगों द्वारा उपयोग किए जाते हैं। – StarTrekRedneck

उत्तर

3

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

+2

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

4

मुझे नहीं लगता कि उन दो संदर्भों के साथ स्वाभाविक रूप से गलत कुछ भी है।

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

यदि "कोर" डोमेन तर्क है, तो आप इसमें कक्षाएं डाल सकते हैं (उदा। IRepository Pattern) जो "डेटा" असेंबली के बारे में जानते हैं। तब आपकी वेब असेंबली को "कोर" के बारे में पता चलेगा, लेकिन "डेटा" नहीं।

इस व्यवस्था को सुविधाजनक बनाने के लिए, आप "डेटाट्रांसफर" नामक चौथी असेंबली बना सकते हैं और कुछ ऑब्जेक्ट्स (या बेहतर, अभी तक इंटरफेस) परिभाषित कर सकते हैं कि "कोर", "डेटा" और "वेब" सभी जानते हैं और संवाद करने के लिए उपयोग करते हैं एक दूसरे के साथ। वास्तव में, यदि आप वास्तव में decoupled प्राप्त करना चाहते हैं, तो "प्रकार" असेंबली वाले इंटरफेस युक्त चीजों को संरचित करना वास्तव में इसे बना सकता है ताकि आपकी मूल तीन विधानसभाओं में से कोई भी एक-दूसरे के बारे में न जान सके।

लेकिन फिर, यदि "कोर" वास्तव में आपके डोमेन तर्क की बजाय एक लाइब्रेरी है, तो शायद यह आपकी वर्तमान संरचना के साथ जाने के लिए समझ में आता है और शायद बाद में इसे फिर से संशोधित करें यदि आप अधिक असेंबली/परतों पर काम करना शुरू करने के लिए पर्याप्त कार्यक्षमता जोड़ते हैं।

संपादित करें: मदद करने के लिए कल्पना मैं क्या मतलब है, मैं एक स्तरित स्थिति के बारे में बात कर रहा हूँ:

Web 
| 
v 
Core 
| 
v 
DataAccess 

बजाय:

Web 
| \ 
v \ 
Core | 
^ | 
| v 
DataAccess 

आप तीन संदर्भ हो जब आप इसके साथ काम कर सकता है दो। अतिरिक्त/अनावश्यक युग्मन बाद में सिरदर्द की ओर जाता है।

+0

सलाह के लिए धन्यवाद। तो यदि कोर अब दूसरे तरीके से डेटा का संदर्भ दे रहा है, तो डेटा किस प्रकार से लौटाएगा/प्राप्त होगा क्योंकि यह कोर के प्रकारों के बारे में नहीं जानता? क्या मुझे कुछ प्रकार के इंटरमीडिएट प्रकारों की आवश्यकता होगी (मुझे लगता है कि डेटा ट्रांसफर असेंबली द्वारा आपका मतलब है)। – DavidGouge

+0

हां, बिल्कुल। "डेटा ट्रांसफर" असेंबली में पीओसीओ या बेहतर, इंटरफेस होंगे कि कोर/डेटा/वेब के बारे में पता चल जाएगा और पैरामीटर और रिटर्न वैल्यू के माध्यम से संवाद करने के लिए उपयोग किया जा सकता है। –

+2

किसी भी तकनीकी कार्यान्वयन, जैसे डेटाबेस, फ़ाइल सिस्टम इत्यादि के संदर्भ में रूट व्यापार तर्क (कोर/डोमेन/आदि) के लिए यह एक गलती है। व्यवसाय अवधारणाओं को अकेले खड़े होना चाहिए। डेटा एक्सेस लेयर एक व्यावसायिक अवधारणा का एक * कार्यान्वयन * है, उदाहरण के लिए, एक IOrderRepository या यहां तक ​​कि एक IRetrieveOrderProcess। यही कारण है कि कोर को DataAccess का संदर्भ नहीं देना चाहिए। – StarTrekRedneck

1

आर्किटेक्चर 1. डेटा 2. व्यवसाय तर्क 3. क्लाइंट है। डेटा डेटा है। व्यापार तर्क डेटा पर काम करता है। क्लाइंट व्यापार तर्क जैसे डेटा-> व्यापार तर्क-> क्लाइंट से जुड़ता है। क्लाइंट डेटा से सीधे कनेक्ट नहीं होता है। 3 परतें डेटा तर्क क्लाइंट।

1

मुझे लगता है कि यह समझ में आता है। जब तक आप व्यवसाय परत से वेब को अलग करते हैं, तो यह आपको व्यवसाय तर्क को आसान तरीके से परीक्षण करने की अनुमति देता है और साथ ही अन्य तरीकों से (जैसे वेब सेवा) के माध्यम से व्यवसाय परत का खुलासा करता है।

9

मुझे लगता है कि आप एक उचित लक्ष्य के लिए प्रयास कर रहे हैं जो एक ठोस अनुप्रयोग वास्तुकला तैयार करेगा। मैंने व्यक्तिगत रूप से एंटरप्राइज़ वेब एप्लिकेशन पर काम किया है जिसने आप वर्णन कर रहे एक समान वास्तुकला का उपयोग किया है, और यह उस एप्लिकेशन के लिए बहुत अच्छा काम करता है।

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

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

  • व्यापार डोमेन में कोई बाहरी संदर्भ के होते हैं:

    कारण यह इतनी अच्छी तरह से है कि आवेदन के लिए काम किया है कि यह लक्ष्य आप अपने प्रश्न में कहा गया है हासिल की है।

  • व्यवसाय डोमेन एप्लिकेशन वेब फ्रंट एंड और डेटाबेस बैक-एंड दोनों से पूरी तरह स्वतंत्र है।

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

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

+0

हाँ! यह है कि यह कैसे किया है, मेरे दोस्तों। – StarTrekRedneck

+0

अच्छी कहानी! (और यदि आपके पास सेवा परत है तो रखरखाव और भी बढ़ जाता है; यूआई और वेब/डेटा सेवा कार्यान्वयन बहुत आसान हो जाता है)। – mikalai

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