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