Йерархия на контролерите
В повечето релсови проекти, които съм виждал, структурата на контролера няма организация и проектът расте сам. В големи проекти това води до огромни контролери (с десетки действия), а условните филтри се разтягат на цял екран. Разбирането на такъв код не е лесно.
След като работих с голям брой релсови проекти, разработих подход за организиране на йерархия от контролери, което направи възможно унифицирането на тяхната структура и опростяването на кода.
Най-високо ниво
На първо място, удобно е да поставите основните пространства от имена на проекта на най-високо ниво, като web, mobile, api, feeds и други. В този случай административният модул ще се намира в web.
Вътре в API можете също да изберете подмодули, разделени по версия, например v1, v2. Или направете папки на най-високо ниво api1, api2 и т.н. връзка: freelancing-gods.com/posts/versioning_your_ap_is
Използвам тази структура дори в най-простите случаи. Практиката показва, че всеки от тези компоненти може лесно да бъде добавен, когато никой не го е планирал.
За всеки модул се създава Namespace::ApplicationController, за да не се смесва логика, подходяща за конкретни пространства от имена.
Но ще има малки разлики в маршрутизирането за различните модули. Web се определя като обхват. В резултат на това ще получим помощници без ненужни префикси, но за останалото се използва пространство от имена.
Вложени ресурси
В този случай също би било разумно да се създадат модули за съответните ресурси.
И за всяко пространство от имена ще има свой собствен ApplicationController, съдържащ общи модулни методи.
За всички контролери, намиращи се в този модул, ще бъдат наличниcurrent_section без филтри.
Контролерите стават все по-малки и по-прости. Разглеждането на структурата на контролерите вече разказва много за това как е организиран проектът и какво може да се очаква в конкретен контролер. Много условни филтри са изчезнали. Тестването е опростено; Единен организационен подход;
Също така, за удобство и еднородност, контролерите за въвеждане на пространство от имена се наричат добре дошли. И те се свързват в маршрути чрез root :to => 'welcome#index' в съответния обхват. Реален пример:
Помислете как да организирате контролери, като използвате реален пример. Да кажем, че е необходимо да се направи интеграция с facebook.
Разделен подход:
В този случай все още не се знае нищо за потребителя, но когато интеграцията се промени (например настройката за автоматично споделяне) или изтриване, ние работим с конкретен потребител. Това може да се реализира, например, така:
В резултат на това вместо един контролер получихме два (но може би повече, ако задачата го изисква), но в същото време всички методи са групирани по случаи на използване.
И тук можете да получите грант за тестов период на Yandex.Cloud. Необходимо е само да въведете "Habr" в полето "секретна парола".