2009-02-10 21 views
20

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

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

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

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

उत्तर

18

हमारे आवेदन को जितना अधिक जटिल हो जाता है, चिंताओं का अधिक महत्वपूर्ण अलगाव बन जाता है।

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

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

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

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

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

+2

मैं जो कहने जा रहा था वह आपके पहले वाक्य द्वारा encapsulated है। +1 सर – annakata

+1

मुझे खेद है कि kloc क्या है? – Coops

+0

मुझे लगता है कि इसका अर्थ है कि किलो कोड कोड। ^^ –

6

यह एक अच्छा सवाल है! कुछ एएसपी.Net डेवलपर के बारे में सोचना चाहिए। आपको शायद बहुत सारे जवाब मिलेंगे, मैं इन बुनियादी आम-विचार विचारों को प्रोत्साहित करता हूं।

- "सफल" आर्किटेक्चर के हिस्से के रूप में डिलीवरी की सादगी और गति पर विचार करें, न केवल "शुद्धता"। वास्तुशिल्प आदर्शों को पकड़ने और व्यावहारिक होने के बीच संतुलन बनाए रखने का प्रयास करें।

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

परतों और कम से कम जटिलता --Keep कोडिंग के समय को कम और पठनीयता और रख-रखाव में सुधार होगा।

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

1

कोड बंदर और पुरी जीवन में किसी अन्य चरमपंथी की तरह बहुत हैं।

हम हा चरम दाएं पंख और चरम बाएं पंख हैं। बहुत कम लोग बिल्कुल एक या दूसरे हैं और वे एक अच्छा मध्य मैदान पाते हैं जहां वे बैठते हैं।अगर यह चरमपंथियों के लिए नहीं था तो हम नहीं जानते कि सीमाएं कहां हैं।

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

2

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

2

हमारे पास एक Winforms ऐप है, और एक एएसपी.NET ऐप है। वे दोनों एक ही बिजनेस ऑब्जेक्ट प्रोजेक्ट (लगभग 140 कक्षाएं) का उपयोग करते हैं।

विनफॉर्म प्रोजेक्ट में लगभग 350 रूप और उपयोगकर्ता नियंत्रण कक्षाएं होती हैं, और इनमें से बहुत कम (< 10) डेटाबेस के बारे में मेटाडेटा की आवश्यकता होती है।

एएसपी.नेट परियोजना में लगभग 100 .aspx पृष्ठ हैं।

हमारे पास 5 कक्षाओं वाली डेटा एक्सेस परत है, जो स्वयं को ADO.NET, धागे और लेन-देन से संबंधित करती है। वे व्यापार ऑब्जेक्ट्स से SQL सर्वर कॉल में अनुरोधों को रूपांतरित करते हैं।

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

बिजनेस लेयर डेटा एक्सेस लेयर की आंतरिक कार्यप्रणालियों के बारे में कुछ भी नहीं जानता है, और जब इसे डेटा की आवश्यकता होती है, तो केवल डीएएल कक्षाओं पर सार्वजनिक विधियों को ही कॉल करता है।

इस तरह की चीज की बात आने पर मैं सभी कट्टरपंथी नहीं हूं, लेकिन हमें इस पर कोनों को काटने की जरूरत नहीं है।

तो संक्षेप में, 100% शुद्ध। यह हमेशा सही करने के लिए हमेशा बेहतर काम करता है।

हमें इस से दूर जाने के लिए एक अच्छा कारण होना चाहिए।

1

कोड जितना बड़ा होगा, जीवनकाल जितना लंबा होगा, उतने ही अलग लोग कोड (दोनों साथ-साथ या जीवनभर के दौरान) पर काम करेंगे, और परतों में अलग-अलग होने की आवश्यकता है। शुरुआत में, यह थोड़ा और अनावश्यक काम प्रतीत होता है, लेकिन लंबे समय तक यह कई बार अपने लिए भुगतान करता है।

अलगाव लागू करने के लिए: यही कारण है कि आपके मुख्य प्रोग्रामर या तकनीकी वास्तुकार को अच्छे सॉफ्ट कौशल के साथ-साथ शुद्ध तकनीकी कौशल की आवश्यकता होती है। आप अलग-अलग अलगाव को लागू करने की कोशिश कर सकते हैं (नीचे देखें) लेकिन अंत में, आपको बड़ी तस्वीरों को साफ रखने के लिए अपने डेवलपर को मनाने (या वाणिज्य) करने की आवश्यकता है।

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