बड़ी संख्या में नियंत्रकों से निपटने के लिए "रेल मार्ग" क्या है?

Question

मेरे रेल अनुप्रयोग में नियंत्रक ढेर करना शुरू कर रहे हैं (> 30)।

क्या यह जावा होगा, मैं बहुत पहले उप-पैकेज बनाना शुरू कर दूंगा, लेकिन मैं यहां थोड़ा संकोच कर रहा हूं। मेरे पास पहले से ही User और Admin नेमस्पेस है लेकिन मुझे यकीन नहीं है कि एक बेहतर नामस्थान संरचना बनाने के लिए अच्छा है, विशेष रूप से रखरखाव पर विचार करना।

इस मामले में "रेल मार्ग" क्या है?

• बस एक कम या कम फ्लैट नियंत्रक संरचना है?
• या क्या उदारतापूर्वक नियंत्रकों को नेमस्पेस/मॉड्यूल में बंडल करना बेहतर है?

अग्रिम धन्यवाद।

Answer 1

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

अधिक समय बीत गया और हमने इसे फ़ोल्डर्स में समूहित करना शुरू किया, उदाहरण के लिए कोच नामक फ़ोल्डर में सभी कोच के लिए सभी संबंधित कार्यक्षमताओं को जाना होगा और नियंत्रक नाम class Coach::SchedulesController < ApplicationController की तरह दिखने लगेंगे।

समूहकरण का यह तरीका कार्यात्मक परीक्षण लिखने में भी मदद करेगा। आप अपने कार्यात्मक परीक्षण को लाइनों की पागल राशि के साथ भी नहीं रखना चाहते हैं।

लेकिन हमेशा रेल के रूप में संकेत एक पतला नियंत्रक और एक वसा मॉडल है। कभी-कभी, इसे पालन करना इतना आसान नहीं हो सकता है और हाँ ये कुछ तरीकों से आप कठिनाइयों को दूर कर सकते हैं।

Answer 2

रेल में, नेमस्पेसिंग नियंत्रक (या यहां तक ​​कि, यूघ, मॉडल) अवांछित है। हाँ, कभी-कभी यह जरूरी है, या सिर्फ सादा आसान है, लेकिन मैं कहूंगा कि यह कभी वांछनीय नहीं है।

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

बेशक यह सभी IMHO है।