सबकुछ कम से कम युग्मित और विस्तार योग्य रखना: बहुत सारी परतें, बहुत छोटी आरओआई?

Question

मैं (अब पहले से कहीं अधिक) को देखने के डेवलपर्स जैसे परतों की भारी मात्रा में लिखें: सी # ब्लॉग के माध्यम खोज रहे हैं

implementation PresentationLayer -> 
    interface IMyDTO -> 
     implementation MyDTO -> 
      interface IMyService -> 
       implementation MyService -> 
        interface IMyDomainRepository -> 
         implementation MyDomainRepository -> 
          interface IMyDomainObject -> 
           implementation MyDomainObject -> 
            interface IMyIndependentStorageLayer -> 
             implementation MyMSSQLStorageLayer 

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

मुझे गलत मत समझो, मुझे विचार पसंद है, लेकिन समय पर व्यापार बंद नहीं है, खासकर एक बड़ी परियोजना पर? क्या रखरखाव में आरओआई वास्तव में इसे उचित ठहराने के लिए काफी बड़ा है?

जो स्पष्टीकरण मैंने पढ़ा है वे अजीब तरह हैं, जैसे कि "अगर मुझे आवश्यकता हो तो मैं एक अलग डेटाबेस संलग्न कर सकता हूं"। वास्तव में? मुझे नहीं लगता कि यह एक आम समस्या है कि कोई अचानक अचानक एमएसएसएलएल से ओरेकल में स्विच करने की मांग करता है और अब आप वहां बैठते हैं और चाहते हैं कि आपके पास दस लाख परतें हों जो सभी एक दूसरे के बारे में नहीं जानते।

क्या ढीले युग्मन के साथ ओवरबोर्ड जाने पर कोई प्रवृत्ति है, या क्या मैं सिर्फ गलत ब्लॉग पढ़ रहा हूं? आप इसके बारे में कैसा महसूस करते हैं, और क्या आपके पास ऐसे उदाहरण थे जहां आप वास्तव में खुश थे कि आपने शुरुआत में अतिरिक्त काम किया था?

Answer 1

सॉफ़्टवेयर के लिए सही व्यापार संरेखित अवधारणा को डिजाइन करना बहुत मुश्किल है। मेरा मतलब एक स्वीकार्य आरओआई के साथ है।

हालांकि, मेरे लिए, परतों की संख्या या सॉफ़्टवेयर अवधारणा के कम युग्मन का स्तर उस संदर्भ के आधार पर है जिसमें सॉफ़्टवेयर का उपयोग किया जाएगा!

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

Answer 2

जाहिर है, इसे ओवरडोन किया जा सकता है, और परतों को जोड़ने के लिए "कहां रुकना है" जानने की आवश्यकता है।

अंगूठे का मेरा नियम यह है कि यदि किसी परत को किसी भी महत्वपूर्ण कार्यक्षमता/कोड को शामिल करने की आवश्यकता नहीं है, तो मुझे इसकी आवश्यकता नहीं है। ऐसा कहा जा रहा है कि, टेस्टेबिलिटी एक महत्वपूर्ण बात है, इसलिए यदि कोई परत मुझे बेहतर टेस्टेबिलिटी खरीदती है, तो मैं इसे जोड़ दूंगा।

Answer 3

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

ऐसा कहा जा रहा है कि, मुझे लगता है कि आपका प्रश्न थोड़ा पक्षपातपूर्ण लगता है। वास्तविक दुनिया में, आप अक्सर एक नए प्रकार की डीबी की मांग करने वाले ग्राहक को नहीं देख सकते हैं, लेकिन आप अक्सर एक नया मूल्यवान व्यक्ति देख सकते हैं जो पिछले की तुलना में उसी प्रकार की डेटा-एक्सेस चाहता है, लेकिन किसी अन्य डीबी पर। यह न केवल आसानी से बदलने के बारे में है, यह कोड-पुन: उपयोग के बारे में भी है।

Answer 4

इन चीजों का मूल्यांकन करते समय मुझे आमतौर पर डीआरवाई सिद्धांत के लेंस के माध्यम से इसे देखने में मदद मिलती है और आपकी परियोजना में नकल की तलाश होती है।

यदि आप एक ऐसी वास्तुकला का उपयोग कर रहे हैं जो आपके प्रोजेक्ट की तुलना में अधिक जटिल है तो आपको कई परतें दिखाई देगी जो अन्य परतों को लपेटने और कॉल पर पास करने के अलावा बहुत कम करती हैं। यह खुद को दोहरा रहा है।

यदि दूसरी ओर आप एक जटिल प्रणाली के लिए पतली वास्तुकला का उपयोग कर रहे हैं तो आप पाएंगे कि सिस्टम के एक हिस्से में कार्यक्षमता बनाने से आपको उस कार्यक्षमता को किसी अन्य भाग में पुन: उपयोग करने की अनुमति नहीं मिलती है, जिससे आप बहुत कुछ लिख सकते हैं जगह पर बहुत समान कोड। यह खुद को दोहरा रहा है।

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

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

Answer 5

एक काल्पनिक उदाहरण परियोजना लें। परीक्षण गति के लिए विभिन्न इन-प्रोसेस SQLite डेटाबेस का उपयोग करते हैं, कुछ डेवलपर के कंप्यूटर पर विकास डेटाबेस PostgreSQL है, स्टेजिंग डेटाबेस एक एकल ओरेकल इंस्टॉल है, और उत्पादन डेटाबेस एक बड़े पैमाने पर मापनीय, बहुत महंगा है, और ओरेकल को कॉन्फ़िगर करने के लिए बहुत कठिन है क्लस्टर।

एसक्यूएल परत को व्यावसायिक परत से अलग किए बिना आप इसे कभी कैसे खींचेंगे?

Answer 6

यह एक हालिया प्रवृत्ति है, और कम अनुभवी लीड/आर्किटेक्ट बैंडविगॉन पर कूदने के शिकार गिर रहे हैं।

परियोजना मैं पर हूँ में, डेटा का उपयोग चला गया:

सेवा इंटरफ़ेस

-> सेवा कार्यान्वयन -> प्रतिनिधि इंटरफ़ेस -> प्रतिनिधि कार्यान्वयन -> डीएओ इंटरफ़ेस -> डीएओ कार्यान्वयन -> Ibatis एक्सएमएल।

यह हमारे मामले में खराब था (और है!), क्योंकि किसी भी प्रतिनिधि कार्यान्वयन विधि में सबसे अधिक कोड एक पंक्ति थी; इसे सिर्फ डीएओ कहा जाता है। प्रत्येक डीएओ के लिए, हमारे पास दो अतिरिक्त कक्षाएं और एक अतिरिक्त बीन कॉन्फ़िगरेशन था, और हम इससे कुछ भी हासिल नहीं कर रहे थे।

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

Answer 7

मैं वर्तमान में एक बड़ी एसओए परियोजना पर काम कर रहा हूं जहां हर परत decoupled था, और लगभग हर वर्ग कुछ अमूर्त कारखाने के माध्यम से तत्काल है। अब हम कुछ मौजूदा कार्यक्षमताओं को अलग-अलग होस्टेड सेवाओं में ऑफ़लोड करने का प्रयास कर रहे हैं, और यह महत्वपूर्ण बिट्स को निकालने की कोशिश कर रहे परतों के माध्यम से एक असली दुःस्वप्न है क्योंकि कभी खत्म होने वाला राइट-क्लिक> परिभाषा पर जाएं ...बाहरीतम परत पर कोड की केवल 1 पंक्ति का पीछा करने के लिए!

प्रति दिन decoupling के साथ कुछ भी गलत नहीं है, और निश्चित रूप से यहां तक ​​कि मेरे प्रोजेक्ट में भी कई क्षेत्रों हैं जहां मुझे एक वास्तुशिल्प दृष्टिकोण से उपयोगी लगता है। बस दूर नहीं ले जाएं ... व्यावहारिक रहें, और उन क्षेत्रों की जांच करते समय पेशेवरों/विपक्षों का वजन करें जिन्हें आप निर्णय लेने के लिए विचार कर रहे हैं।

चीयर्स