क्या एन-टियर समाधान का उपयोग करने के लिए कोई नकारात्मक कारण हैं?

Question

मैं अपनी कंपनी (2 सप्ताह) में काफी नया हूं और हम डॉटनेटनेट से .NET 3.5 टीम फाउंडेशन का उपयोग करके हमारे सिस्टम के लिए एक नया मंच शुरू कर रहे हैं। हमारा "वास्तुकार" सुझाव दे रहा है कि हम एक वर्ग परियोजना का उपयोग करें। बेशक, मैं एक "3-स्तरीय" वास्तुकला (व्यापार, डेटा, वेब वर्ग परियोजनाओं) के साथ वापस झुकता हूं।

क्या इस वास्तुकला का उपयोग करने के लिए कोई नुकसान है? प्रो डेटा से कोड को अलग करेगा, क्लास ऑब्जेक्ट्स को आपके कोड से दूर रखेगा, आदि

Answer 1

मुझे लगता है कि काफी बड़ा नकारात्मक पक्ष यह है कि छोटे परियोजना के लिए आपको लिखने, प्रबंधित करने और बनाए रखने के लिए कोड की अतिरिक्त मात्रा केवल ओवरकिल हो सकती है।

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

Answer 2

यह 3-टाइयर बनाने के लिए एक अनुभवहीन टीम को अधिक समय लेता है। यह अधिक कोड है, और अधिक बग। मैं सिर्फ शैतान के वकील को खेल रहा हूं।

Answer 3

मैं एन टायर दृष्टिकोण के लिए कड़ी मेहनत कर रहा हूं भले ही यह एक छोटी परियोजना हो। यदि आप कोडरमिथ + नेटटीर्स जैसे ओआरएम टूल का उपयोग करते हैं तो आप परियोजनाओं को जल्दी से स्थापित करने और कोड विकसित करने में सक्षम होंगे जो आपकी व्यावसायिक समस्याओं को जल्दी हल करता है।

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

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

Answer 4

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

इसके अलावा, भले ही आपका सिस्टम इस समय छोटा हो, फिर भी आप इसमें और अधिक सुविधाएं जोड़ना चाहेंगे - एन-टियर नहीं जा सकता आपके हिस्से पर तकनीकी ऋण का एक प्रकार है, इसलिए आपको सावधान रहे।

Answer 5

क्योंकि आप विभिन्न भौतिक स्तरों पर परतों को वितरित करने में सक्षम होने का क्षमता चाहते हैं (मैं हमेशा शारीरिक के लिए "टायर", और तार्किक के लिए "परत" का उपयोग करें), तो आप सिर्फ एक में सब कुछ देने से पहले दो बार सोचना चाहिए कक्षा क्योंकि अगर आपको वितरण शुरू करने की आवश्यकता होती है तो आपको करने के लिए प्रमुख रिफैक्टरिंग मिलती है।

Answer 6

एकमात्र नुकसान जटिलता है लेकिन वास्तव में कुछ डोमेन ऑब्जेक्ट्स जोड़ने और डेटासेट का उपयोग करने के विरोध में उनकी सूची में बाध्य करना कितना मुश्किल है। आपको तीन अलग-अलग परियोजनाओं को भी बनाने की ज़रूरत नहीं है, आप केवल वेब ऐप के भीतर 3 अलग-अलग फ़ोल्डर्स बना सकते हैं और प्रत्येक को नामस्थान जैसे आपका कॉम्पैनी.आप ऐप.डोमेन, YourCompany.YourApp.Data, आदि

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

शायद अल्प अवधि में आप बहुत ही सरल डोमेन ऑब्जेक्ट्स बनाकर और डेटासेट से पॉप्युलेट करके एक साधारण समाधान पर ध्यान केंद्रित करते हैं, तो आप आवश्यकतानुसार व्यवसाय तर्क जोड़ सकते हैं और आवश्यकतानुसार अधिक परिष्कृत ओआरएम बना सकते हैं, या निबर्ननेट का उपयोग कर सकते हैं ।