Ієрархія контролерів
У більшості зустрічалися мені проекти rails, структура контролерів не має ніякої організації і проект зростає як доведеться. У великих проектах це призводить до того, що контролери стають величезними (з десятками actions), а умовні фільтри розтягуються на весь екран. Розібратися в такому коді дуже непросто.
Попрацювавши з великою кількістю проектів rails, у мене був сформований підхід до організації ієрархії контролерів, яка дозволила уніфікувати їх структуру і спростити код.
Верхній рівень
Насамперед зручно на верхньому рівні розташувати основні неймспейси проекту, такі як web, mobile, api, feeds та інші. При цьому модуль admin перебуватиме у web.
Всередині апі можна виділити підмодулі, розділені за версією, наприклад, v1, v2. Або робити папки на верхньому рівні api1, api2 тощо. link: freelancing-gods.com/posts/versioning_your_ap_is
Я використовую таку структуру навіть у найпростіших випадках. Практика показує, що будь-яка з цих складових легко може додатись тоді, коли цього ніхто не планував.
Для кожного модуля створюється Namespace::ApplicationController для того, щоб не змішувати логіку, що підходить для конкретних неймспейсів.
Але у роутингу будуть невеликі відмінності для різних модулів. Web задається як scope. В результаті ми отримаємо хелпери без зайвих префіксів, а ось для інших використовується namespace.
Вкладені ресурси
У цьому випадку буде розумним створити модулі для відповідних ресурсів.
І для кожного неймспейсу буде власний ApplicationController, що містить загальні методи модуля.
Для всіх контролерів, що знаходяться в цьому модулі, буде доступнийcurrent_section без фільтрів.
Контролери стають менше та простіше. Дивлячись на структуру контролерів вже багато можна сказати про те, як організований проект і чого можна очікувати в конкретному контролері. Має багато умовних фільтрів. Спрощується тестування; Єдиний організаційний підхід;
Так само, для зручності та однаковості, вхідні контролери неймспейсу обзиваються welcome. І підключаються в роутах через root: to => 'welcome#index' усередині відповідного scope. Реальний приклад:
Розглянемо як організувати контролери реальному прикладі. Допустимо потрібно було зробити інтеграцію з facebook.
Підхід із поділом:
У даному випадку про користувача ще нічого не відомо, а ось при зміні інтеграції (наприклад, налаштування автошарингу) або видаленні ми працюємо з конкретним користувачем. Це можна реалізувати, наприклад, так:
У результаті замість одного контролера ми отримали два (але може бути і більше, якщо завдання цього вимагатиме), але при цьому всі методи згруповані за варіантами використання.
А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»