क्या छोटे (आईएसएच) अनुप्रयोगों के लिए 3-स्तरीय आर्किटेक्चर का उपयोग करना उचित है

Question

मैं अपेक्षाकृत छोटे एएसपीनेट वेब एप्लिकेशन पर काम कर रहा हूं और सोच रहा हूं कि पूर्ण एन-स्तरीय आर्किटेक्चर को वास्तव में नियोजित करने की आवश्यकता है या नहीं। आकार के विचार के लिए; लगभग 20 डेटाबेस टेबल हैं।

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

क्या कोई थ्रेसहोल्ड आकार या अंगूठे का कुछ नियम है जहां आपको एन-स्तरीय कार्य करना चाहिए?

Answer 1

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

Answer 2

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

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

तो अंगूठे का आपका शासन इस बात से शासित है कि परिवर्तन के लिए कौन भुगतान करेगा और कब।

Answer 3

वहाँ एक सीमा आकार या अंगूठे के कुछ नियम जहां n स्तरीय रोजगार चाहिए है?

नहीं एक है कि मैं के बारे में पता है, लेकिन मैं इस बाहर फेंक देंगे: इस बात की संभावना यह वेब एप्लिकेशन बढ़ सकता है अगर (या बैकेंड बदल) और/या किसी और इसे बनाए रखने खत्म हो सकता है, मैं एक एन-स्तरीय दृष्टिकोण के साथ जाने पर विचार करें।

Answer 4

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

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

Answer 5

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

आखिरी परियोजना जिस पर मैंने काम किया (देर से आया) इस तरह लिखा गया था कि स्तरों को तोड़ना व्यावहारिक रूप से असंभव था। प्रस्तुति तर्क के साथ जुड़े व्यापार तर्क के साथ जुड़े डेटा तर्क। संक्षेप में, यह उतना अच्छा था जितना कि यह कभी भी होने वाला था क्योंकि इसे ठीक करने में कई महीने लग गए थे।

सब कुछ अलग रखना मुश्किल नहीं है जैसा कि मैंने पहले कहा था, बस इसे संभव रखें।