Этот подход к толстой модели / тощему контроллеру заходит слишком далеко?

Question

Боюсь, что мне может стать ленивым.

Я занимаюсь разработкой приложения ruby ​​on rails с участием около 8 моделей, относящихся к двум типам пользователей: врачам и пациентам. Большая часть логики находится внутри моделей, что позволяет моим действиям контроллера быть очень короткими и краткими. Кроме того, это делает тестирование довольно простым.

В настоящее время я представляю по крайней мере два контроллера, и тесты, которые я пишу, наводят меня на мысль, что большинство моих пользовательских функций могут обрабатываться этими двумя контроллерами. Конечно, я могу разбить это на более осмысленные тесты, подобные тестам для пациента-диспетчера, врача-диспетчера, диспетчера лекарств для пациента, диспетчера результатов пациента-лаборатории и так далее. Но мне кажется, что единственным преимуществом здесь является более сдержанная организация.

Что касается вопроса, помимо разделения, то по каким причинам НЕ следует использовать как можно меньше контроллеров, упаковывать их множеством действий [недостатков], но при этом делать действия скиновыми [преимуществами]? Или ... чтобы довести это до крайности: почему бы не с MVC, иметь кучу толстых моделей и один тощий [хотя и длинный] контроллер, а не контроллер пациента / модель / виды + тесты для КАЖДОГО, врачский контроллер / модель / просмотры + тесты на КАЖДЫЙ и т. д.?

Answer 1

Есть организация, так как все внутри одного контроллера возможно, понять и изменить будет сложнее.Вместо того, чтобы открывать файл в редакторе и сразу же находить искомое действие, вы прокручиваете файл вниз, чтобы найти то, что ищете.

Это также приводит к Шаблон объекта Бога , где все происходит внутри одного объекта, который отвечает за все, и каждый, кто работает над проектом, будет менять этот же объект, что приведет к вечному адскому слиянию.

И на Railsсама по себе есть RESTful-ность фреймворка.Rails охватывает идею RESTful, и одним из столпов этой идеи являются ресурсы, и они могут быть легко организованы только в отдельных контроллерах.Если вы попытаетесь разместить два разных ресурса на одном контроллере, вы, вероятно, в конечном итоге получите сумасшедшие маршруты или сумасшедшую логику контроллера, чтобы выяснить, какая модель представлена.

Если вы считаете, что у ваших контроллеров много повторенийкод, вы можете высушить их, используя магию или соглашения метапрограммирования, но действительно лучше разделить их, не только для организации, но и для упрощения вашего будущего обслуживания.

Answer 2

На этот вопрос невозможно ответить. Контроллеры - это маршруты и взаимодействия с пользователем, а не бизнес-логика Имейте столько контроллеров и действий, сколько имеет смысл для ваших ссылок и просмотров!

Если ваша бизнес-логика все в ваших моделях, то это достаточно просто. Основная проблема с логикой в ​​контроллерах заключается в том, что вы не можете повторно использовать логику.

Больше нечего сказать. Вам решать, что имеет смысл в вашем приложении. например иметь контроллер поиска для поиска вещей, а не добавлять действие поиска к существующим контроллерам на самом деле не о чем-то большем, чем разделение и ясность

Answer 3

Если есть много общей логики контроллера, вы можете рассмотреть возможность абстрагирования его в плагин или модуль, который вы можете смешивать при необходимости.Или контроллеры могут наследовать от общего базового контроллера (так же, как все контроллеры наследуются по умолчанию от ApplicationController, а не ActionController::Base).

Я бы посоветовал не иметь один гигантский контроллер;Контроллер должен управлять набором действий, которые относятся к одному типу ресурса (или к ближайшему из возможных аналогов).Эта идея еще сильнее, если вы пытаетесь создать дизайн RESTful, в котором каждый контроллер обычно не имеет ничего, кроме семи основных действий (индексировать, показывать, создавать, редактировать, обновлять, уничтожать).

Поэтому, если вы хотите, чтобы URL-адреса типа /patients/52394802/lab_results, я думаю, имеет смысл иметь LabResultsController.Если эти контроллеры легкие, то круто.Я придерживаюсь мнения, что их существование все еще оправдано.Это не должно мешать вам пытаться сделать ваш код СУХИМ;скорее, я бы просто попытался абстрагироваться от общей функциональности по-другому.