मुझे अपनी कंपनी में हमारे कोड बेस के लिए एक नई वास्तुकला की नींव बनाने शुरू करने के लिए आगे बढ़ना पड़ा है। इस पहल के लिए प्रोत्साहन तथ्य यह है कि:एक सख्त स्तरित वास्तुकला में अलग परतों को तोड़ने और अनावश्यक अनावश्यकता के बिना मॉड्यूलरिटी को बढ़ावा देने के लिए कैसे?
- हमारा कोड बेस दस साल से अधिक पुराना है और अंत में हम पैमाने पर तोड़ने की कोशिश करते हैं।
- शीर्ष "परतें", यदि आप उन्हें कॉल करना चाहते हैं, तो क्लासिक एएसपी और .NET की गड़बड़ है।
- हमारा डेटाबेस अपवित्र संग्रहित प्रोसेस का एक गुच्छा से भरा हुआ है जिसमें व्यापार तर्क और सत्यापन की हजारों लाइनें शामिल हैं।
- पहले डेवलपर्स ने "चालाक" समाधान बनाए जो गैर-विस्तारणीय, गैर-पुन: प्रयोज्य हैं, और बहुत स्पष्ट विरोधी पैटर्न प्रदर्शित करते हैं; इन्हें शॉर्ट ऑर्डर में बहिष्कृत करने की आवश्यकता है।
मैं MS Patterns and Practices Architecture Guide काफी भारी मैं एक प्रारंभिक डिजाइन की ओर काम के रूप में संदर्भित किया गया है, लेकिन मैं अभी भी कुछ सुस्त प्रश्न पूछना चाहते हैं इससे पहले कि मैं कुछ भी करने के लिए प्रतिबद्ध।
(उच्च स्तर)
(गहराई में व्यापार और डाटा परतों)
आरेख मूल रूप से दिखाते हैं कि मैं प्रत्येक परत को कई असेंबली में अलग करने का इरादा रखता हूं। तो इस उम्मीदवार वास्तुकला में, हमारे पास ग्यारह असेंबली होगी, जिसमें शीर्षतम परतें शामिल नहीं हैं।
यहाँ टूटने है, प्रत्येक विधानसभा के विवरण के साथ:
Company.Project.Common.OperationalManagement: घटकों जो अपवाद संचालन नीतियों, प्रवेश, प्रदर्शन काउंटरों, विन्यास, और ट्रेसिंग लागू होता है।Company.Project.Common.Security: ऐसे घटक शामिल हैं जो प्रमाणीकरण, प्रमाणीकरण और सत्यापन करते हैं।Company.Project.Common.Communication: उन घटकों को शामिल करता है जिनका उपयोग अन्य सेवाओं और अनुप्रयोगों (मूल रूप से पुन: प्रयोज्य डब्ल्यूसीएफ क्लाइंट्स का एक गुच्छा) के साथ संवाद करने के लिए किया जा सकता है।Company.Project.Business.Interfaces: इंटरफेस और अमूर्त कक्षाएं शामिल हैं जिनका उपयोग उच्च स्तर की परतों से व्यापार परत के साथ बातचीत करने के लिए किया जाता है।Company.Project.Business.Workflows: व्यापार वर्कफ़्लो के निर्माण और रखरखाव से संबंधित घटकों और तर्क शामिल हैं।Company.Project.Business.Components: ऐसे घटक शामिल हैं जो व्यवसाय नियमों और सत्यापन को समाहित करते हैं।Company.Project.Business.Entities: डेटा ऑब्जेक्ट्स जो उच्च स्तर पर व्यावसायिक संस्थाओं के प्रतिनिधि हैं। इनमें से कुछ अद्वितीय हो सकते हैं, कुछ डेटा परत से अधिक दानेदार डेटा इकाइयों से बना कंपोजिट हो सकते हैं।Company.Project.Data.Interfaces: इंटरफ़ेस और सार कक्षाएं शामिल हैं जिनका उपयोग एक भंडार शैली में डेटा एक्सेस परत के साथ संवाद करने के लिए किया जाता है।Company.Project.Data.ServiceGateways: सेवा क्लाइंट और घटक शामिल हैं जिनका उपयोग बाहरी सिस्टम से डेटा को कॉल करने और लाने के लिए किया जाता है।Company.Project.Data.Components: ऐसे घटक शामिल हैं जिनका उपयोग डेटाबेस के साथ संवाद करने के लिए किया जाता है।Company.Project.Data.Entities: इसमें अधिक ग्रैन्युलर इकाइयां शामिल हैं जो कम स्तर पर व्यावसायिक डेटा का प्रतिनिधित्व करती हैं, जो किसी डेटाबेस या अन्य डेटा स्रोत को लेनदेन के तरीके में कायम रखने के लिए उपयुक्त होती हैं।
मेरे इरादे है कि यह एक सख्त स्तरित डिजाइन (एक परत केवल सीधे नीचे परत के साथ संवाद कर सकते हैं) और परतों की मॉड्यूलर ब्रेक डाउन उच्च एकता और ढीला संयोजन को बढ़ावा देना चाहिए होना चाहिए। लेकिन मुझे अभी भी कुछ चिंताएं हैं। यहाँ मेरे सवालों का है, जो मुझे लगता है पर्याप्त उद्देश्य है कि वे इतने पर यहां उपयुक्त हैं रहे हैं ...
- मानक सम्मेलनों निम्नलिखित प्रत्येक मॉड्यूल और अपने संबंधित विधानसभा के लिए मेरे नामकरण सम्मेलनों हैं, या वहाँ मैं चाहिए एक अलग तरीका है कर रहे हैं इस बारे में जा रहे हो?
- क्या कई असेंबली में व्यापार और डेटा परतों को अलग करना फायदेमंद है?
- क्या यह प्रत्येक परत के लिए इंटरफेस और अमूर्त कक्षाएं अपने स्वयं के असेंबली में फायदेमंद है?
- सबसे महत्वपूर्ण - क्या यह व्यवसाय और डेटा परत दोनों के लिए "संस्थाएं" असेंबली के लिए फायदेमंद है? मेरी चिंता यह है कि यदि आप उन वर्गों को शामिल करते हैं जो डेटा एक्सेस घटकों के अंदर LINQ से SQL द्वारा जेनरेट की जाएंगी, तो कोड आधार में तीन अलग-अलग स्थानों में दी गई इकाई का प्रतिनिधित्व किया जाएगा। स्पष्ट रूप से ऑटोमैपर जैसे टूल मदद करने में सक्षम हो सकते हैं, लेकिन मैं अभी भी 100% नहीं हूं। कारण यह है कि मैंने उन्हें अलग कर दिया है ए - ए सख्त-स्तरित आर्किटेक्चर को लागू करना और बी - परतों के बीच एक लूसर युग्मन को बढ़ावा देना और प्रत्येक इकाई के पीछे व्यापार डोमेन में परिवर्तन करते समय ब्रेकेज को कम करना। हालांकि, मैं उन लोगों से कुछ मार्गदर्शन प्राप्त करना चाहता हूं जो आर्किटेक्चर में ज्यादा अनुभवी हैं।
यदि आप मेरे प्रश्नों का उत्तर दे सकते हैं या मुझे सही दिशा में इंगित कर सकते हैं तो मैं सबसे अधिक आभारी हूं। धन्यवाद।
संपादित करें: कुछ अतिरिक्त जानकारी है कि बबून के जवाब को पढ़ने के बाद और अधिक उचित होने लगते हैं शामिल करने के लिए चाहता था। डेटाबेस टेबल भी एक अपवित्र गड़बड़ हैं और सर्वोत्तम रूप से अर्ध-संबंधपरक हैं। हालांकि, मुझे डेटाबेस को पूरी तरह से पुन: व्यवस्थित करने की अनुमति नहीं है और डेटा साफ-सफाई करने की अनुमति नहीं है: मैं जिस कोर को जा सकता हूं, वह सबसे पहले नीचे संग्रहीत प्रोसेस बनाने और पुराने लोगों को बहिष्कृत करना शुरू कर सकता है। यही कारण है कि मैं डेटा परत में स्पष्ट रूप से परिभाषित संस्थाओं की ओर झुका रहा हूं - LINQ से SQL (या किसी अन्य ओआरएम) द्वारा उत्पन्न कक्षाओं का उपयोग करने के लिए डेटा इकाइयों के रूप में केवल व्यवहार्य प्रतीत नहीं होता है।
2012-03-05 के रूप में अपडेट करें: हमने योजनाबद्ध रूप से सख्त स्तरित वास्तुकला के साथ जाने का फैसला किया है। हालांकि, मैं अंततः इस निष्कर्ष पर पहुंचा कि अपनी स्वयं की असेंबली में इंटरफेस और अमूर्त वर्गों को केवल वास्तविक लाभ के साथ जटिलता जोड़ा गया था। मैं अभी भी अलग-अलग व्यावसायिक संस्थाओं के दृष्टिकोण के साथ जा रहा हूं, जो डेटा परत में इकाइयों से अलग हैं। यह अमूल्य साबित हुआ है, क्योंकि यह व्यापार परत के पीछे घूमने से डीबी स्कीमा के घृणास्पद विवरण रखता है। दूसरे शब्दों में, यह रेत में एक रेखा खींचने में मदद करता है और सुरक्षा जोड़ा जाता है। –