Цей підхід до моделі контролера з низьким вмістом жиру заходить занадто далеко
Боюсь, що я можу лінуватися.
Ми розробили додаток з рубіновою рейкою, що включає близько 8 моделей для двох типів користувачів: лікарів та пацієнтів. Більша частина логіки знаходиться всередині моделей, які дозволяють моїй дії контролера бути дуже короткими та стислими. Крім того, це робить тестування досить простим.
В даний час я бачу принаймні два елементи управління, і тести, які я пишу, змушують мене думати, що більшість моїх функцій, з якими стикаються користувачі, можуть керуватися цими двома контролерами. Звичайно, я можу розбити це на більш чутливі відділення - такі як тести для пацієнта-контролера, лікаря-контролера, пацієнта-контролера, пацієнта-лабораторії-результатів-контролера тощо. Але мені здається, що єдиною перевагою тут є більш стримана організація.
На запитання, окрім компартменталізації, у чому причини не використовувати якомога менше контролерів, поєднати їх з великою кількістю дій [недолік], але тримати дії тонкими [перевага]? Або дойдіть до крайності: чому б не з MVC, у вас багато жирових моделей і слабкий контролер [хоч і довгий], а не контролер пацієнта/модель/думки + тести для кожного, лікар контролер/модель/думки + тести для кожного тощо?
3 відповіді
Існує організація, тому що все, що робить один контролер, можливо, це буде важче зрозуміти і змінити. Замість можливості відкрити файл у своєму редакторі та негайно знайти дію, яку ви шукаєте, прокрутіть файл, щоб знайти те, що ви шукаєте.
Це також призводить до моделі Предмет Бога в якому все відбувається всередині одного об'єкта, який відповідає за все, і кожен, хто працює над проектом, змінить той самий об'єкт, що призведе до старого пекла злиття.
І на самому Rails є РЕАЛЬНІСТЬ кадру. Rails охоплює ідею бути RESTful і одним із стовпів цієї ідеї є ресурси, і їх легко організувати лише в окремих контролерах. Якщо ви спробуєте розмістити два різні ресурси на одному контролері, ви, мабуть, отримаєте божевільні маршрути або божевільний логічний контролер, щоб дізнатися, яка модель представлена.
Якщо ви вважаєте, що ваші драйвери мають багато повторюваних кодів, ви можете видалити їх за допомогою декількох мета-програм або умов, але навіть краще розділити їх не лише для організації, але й для спрощення подальшого обслуговування.
На це питання неможливо відповісти. Контролери стосуються користувацьких маршрутів та взаємодій та бачень, а не ділової логіки. У вас стільки контролерів та дій, скільки має сенс мати для ваших зв’язків та думок.!
Якщо у ваших моделях вся бізнес-логіка, то це досить просто. Основна складність логіки в контролерах полягає в тому, що ви не можете повторно використовувати логіку.
Більше нічого сказати. Наприклад, ви повинні робити те, що має сенс у вашому додатку. у вас є контролер пошуку для пошуку речей, а не додавання дії пошуку до ваших існуючих контролерів - це насправді не що інше, як поділ та чіткість
Якщо існує багато загальної логіки контролера, ми рекомендуємо вам витягти її у плагін або як можна змішати його, коли це потрібно. Або елементи керування можуть успадковуватися від загального базового контролера (подібно до того, як усі контролери успадковуються від ApplicationController за замовчуванням, а не від ActionController: Base).
Я б порадив вам не мати гігантського контролера; контролер повинен керувати набором дій, що стосуються одного типу ресурсу (або найближчого можливого аналога). Ця ідея ще сильніша, якщо ви спробуєте створити RESTful дизайн, в якому кожен контролер зазвичай не має нічого, крім семи основних дій (індексація, представлення, створення, редагування, оновлення, знищення).
Отже, якщо ви хочете мати такі URL-адреси, як/Patients/52394802/lab_results, я вважаю, що має сенс мати LabResultsController. Якщо ці елементи управління прості, чудові. Я вважаю, що їх існування все ще виправдане. Це не завадить вам намагатися отримати СУХИЙ код; швидше, я намагався б зловживати загальноприйнятою функціональністю інакше.