Какой подход в MVC дизайне более эффективный и как они правильно называются?

Question

[ixon]

Допустим, нам следует реализовать авторизацию и регистрацию пользователей на сайте. Тогда мы можем создать контроллер users и использовать его в качестве инструмента для вызова нескольких моделей: для регистрации пользователя, для авторизации, для вывода списка пользователей и соответствующих видов для каждого случая.
Или же мы можем сделать контроллеры users_registration, users_authorithation, users_list для регистрации, авторизации и вывода списка пользователей. И аналогичные для каждого из них модели и виды.

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

Comments

[Толстый Лорри]

user_authentication (который выдаёт куку/токен и т.п.), ибо авторизацией (в праве ли этот юзер делать действие X?), как правило, занимается сервис, вызовы которого размазаны по другим контроллерам.

Answer 1

[Денис Дерепко]

Для этого хватит одного контроллера с парой методов.

Не нужно нагромождать контроллеры, но и до абсурда доводить тоже не надо.
Метод в контроллере должен вызвать модель и передать результат во вьюху, поэтому кода будет не много

Помимо MVC есть другие подходы - Тык

Answer 2

[Северное Сияние]

Или же мы можем сделать контроллеры users_registration, users_authorithation, users_list для регистрации, авторизации и вывода списка пользователей.

Я когда на заре своего веб-программизма писал свой фреймворк, то пошел по этому пути. Это очень удобно скажу я вам - контроллеры относительно небольшие, не перегружены кодом, в каждом есть лишь один метод run(). Вот пример контроллера удаления пользователя, который вызывается из административной части. На это действие лишь один контроллер. Все. Никакого лишнего кода, который бы мог бы быть, если бы я использовал один общий UserController.

Дело в том, что в реальной жизни от ТТУК избавиться довольно сложно, вот пример контроллера регистрации, который должен как вызвать методы сохранения модели, так и сделать неявную авторизацию + отправить письмо + некие иные действия. Он уже поболее размером.

Поэтому я за данный подход.

Comments

[Дмитрий]

Дело в том, что в реальной жизни от ТТУК избавиться довольно сложно

Что сложного перенести логику из контроллера в сервис?

[Северное Сияние]

Дмитрий,

Что сложного перенести логику из контроллера в сервис?

зависит от конкретного контролера. Допустим, надо сделать вывод списка записей - тут легко - делаем сервис, оперирующий получением данных, зашиваем в него логику по сортировке из Request-a.

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

Answer 3

[Леонид]

cfvsq эфективный подход как не использовать MVC который в вебе как на корове седло