नियंत्रक पदानुक्रम

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

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

शीर्ष स्तर

सबसे पहले, ऊपरी स्तर पर मुख्य परियोजना के नाम, जैसे कि वेब, मोबाइल, एपीआई, फीड और अन्य की व्यवस्था करना सुविधाजनक है। इस मामले में, व्यवस्थापक मॉड्यूल वेब पर स्थित होगा।



एपीआई के अंदर, आप संस्करण द्वारा विभाजित सबमॉड्यूल भी चुन सकते हैं, उदाहरण के लिए, v1, वी 2। या शीर्ष स्तर एपी 1, एपी 2, आदि पर फ़ोल्डर्स बनाएं।
लिंक: फ्रीलांसिंग- gods.com/posts/versioning_your_ap_is

मैं इस तरह की संरचना का उपयोग सरलतम मामलों में भी करता हूं। अभ्यास से पता चलता है कि इनमें से कोई भी घटक आसानी से जोड़ा जा सकता है जब किसी ने इसकी योजना नहीं बनाई है।

प्रत्येक मॉड्यूल के लिए, विशिष्ट नामस्थान के लिए उपयुक्त तर्क को न मिलाने के लिए एक नामस्थान :: ApplicationController बनाया जाता है।



लेकिन रूटिंग में विभिन्न मॉड्यूल के लिए छोटे अंतर होंगे। वेब स्कोप के रूप में सेट है। परिणामस्वरूप, हमें अनावश्यक उपसर्गों के बिना मदद मिलती है, लेकिन नाम स्थान का उपयोग बाकी के लिए किया जाता है।

नेस्टेड संसाधन

मैं एक उदाहरण के साथ तुरंत शुरू करूँगा: एक साइट पर एक उपयोगकर्ता प्रोफ़ाइल। इसे url / users /: id और इसके UsersController कंट्रोलर के जरिए एक्सेस किया जा सकता है। उपयोगकर्ता पदों की एक सूची / उपयोगकर्ताओं /: आईडी / पदों पर उपलब्ध है। तदनुसार, हमारे पास एक अनुक्रमणिका के साथ एक पोस्टकंट्रोलर है जिसके अंदर हम उपयोगकर्ता द्वारा पोस्ट प्राप्त करते हैं। फिर हमारे पास एक सूची में सभी पदों को प्रदर्शित करने का कार्य है। हम समान पोस्ट कंट्रोलर का उपयोग करते हैं और वहां index_all विधि जोड़ते हैं। इसी समय, उपयोगकर्ता को अब यहां की आवश्यकता नहीं है। अंत में, बहुत सारे विचारों को जोड़ते हुए, कुछ तरीके होंगे जो उपयोगकर्ता के लिए इन पदों (और उन्हें संसाधित करें) को प्रदर्शित करते हैं, और कुछ इसके बिना। फिर फिल्टर होंगे, उदाहरण के लिए, पहले_फिल्टर: load_user,: केवल => [: इंडेक्स ...], और इस तरह जब तक कि लोग शेष हैं जो समझ सकते हैं कि यहां क्या हो रहा है।

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

इस मामले में, संगत संसाधनों के लिए मॉड्यूल बनाना भी बुद्धिमानी होगी।



और प्रत्येक नाम स्थान के लिए अपने स्वयं के ApplicationController होगा जिसमें सामान्य मॉड्यूल विधियां होंगी।



इस मॉड्यूल में स्थित सभी नियंत्रकों के लिए, बिना फ़िल्टर के current_section उपलब्ध होगा।

लाभ:

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

इसके अलावा, सुविधा और एकरूपता के लिए, नाम स्थान इनपुट नियंत्रकों को स्वागत योग्य कहा जाता है। और वे रूट के माध्यम से मार्गों से जुड़े हुए हैं: => इसी दायरे के अंदर 'स्वागत # सूचकांक'।
वास्तविक उदाहरण:

आइए विचार करें कि वास्तविक उदाहरण पर नियंत्रकों को कैसे व्यवस्थित किया जाए। मान लीजिए आपको फेसबुक के साथ एकीकरण करने की आवश्यकता है।

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

पृथक्करण दृष्टिकोण:

resource :facebook, :only => [:new, :create] 

इस मामले में, उपयोगकर्ता के बारे में अभी तक कुछ भी ज्ञात नहीं है, लेकिन एकीकरण को बदलते समय (उदाहरण के लिए, ऑटो-शेयरिंग सेट करना) या हटाना, हम एक विशिष्ट उपयोगकर्ता के साथ काम करते हैं। इसे इस तरह से लागू किया जा सकता है:

 # app/controllers/web/account/facebook_controller.rb resource :account do scope :module => :account do resource :facebook, :only => [:edit, :update, :destroy] end end 

और अगर आपको पहले से अधिकृत उपयोगकर्ता को एकीकृत करने का अवसर देने की आवश्यकता है? फिर अंतिम उदाहरण में जोड़ें: नया,: बनाएँ।

नतीजतन, एक नियंत्रक के बजाय, हमें दो (लेकिन शायद अधिक अगर कार्य की आवश्यकता होती है) मिला, लेकिन एक ही समय में, सभी तरीकों का उपयोग मामलों द्वारा समूहीकृत किया जाता है।