По какому принципу создавать контроллеры в MVC?

Question

[Дмитрий Яковлев]

К примеру есть сущность product. Можно создать ProductController и в нем будут методы как для админки так и для сайта. Или же сделать 2 контролера (для сайта и админки). Или вообще разбить по функционалу: ProductOrderController - только заказ товара, ProductController - здесь только crud методы, ProductReviewController - тут опысывается логика недавно просмотренных товаров и так далее.

Как вы поступаете в своих проектах ?

Comments

[Сергей delphinpro]

Логика в моделях.

Я бы разбил на админку и сайт. Админку вообще отдельным приложением.

Разбиение на части - ну если Product получается слишком большой, не грех его и на части разбить.

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

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

Answer 1

[BoShurik]

Catalog
    Controller
        Admin
            ProductController.php
        ProductController.php # ReviewManager используется тут
    Entity
        Product.php
        Review.php
    ReviewManager.php
Order
    Controller
        Admin
            OrderController.php
        OrderController.php
    Entity
        Order.php
        Item.php
User
    Controller
        Admin
            UserController.php
        UserController.php
    Entity
        User.php

либо

Controller
    Admin
        Catalog
            ProductController.php
        Order
            OrderController.php
        User
            UserController.php
    Catalog
        ProductController.php # ReviewManager используется тут
    Order
        OrderController.php
    User
        UserController.php
Entity
    Catalog
        Product.php
        Review.php
    Order
        Order.php
        Item.php
    User
        User.php
Catalog
    ReviewManager.php

как больше нравится

Не уверен нужен ли ReviewController, зависит от функциональности. Если это просто виджет на странице с недавними товарами, сделал бы в публичном ProductController

Answer 2

[FanatPHP]

Контроллер должен быть тонким.
А тонких не проблема сделать несколько - все равно никакой функциональности в них быть не должно - она должна лежать в репозитории и хелпере.

Так что делаем productRepozitory в котором пишем всю работу с БД
и productHelper, в котором пишем всю пхп логику
и дальше из контроллеров только дергаем методы хелпера

Answer 3

[voronkovich]

Если crud'ов много я использую SyliusResourceBundle. Для всего остального - отдельные контроллеры.
Есть подход: один контроллер - один класс. С autowiring это может быть реализовано очень легко.

Comments

[Николай Егоров]

А этот бандл поддерживает SF4?

[voronkovich]

Николай Егоров, Пока нет. Но, в интервью один из разработчиков говорил, что поддержка Symfony 4 планируется. См. Interview with Paweł Jędrzejewski, founder of Syli....

[Николай Егоров]

Спасибо за ответ!

Answer 4

[zugo]

Контекст -> Операция.
Например, AuthController с методами register, login, invalidateToken и т.д.
А если мыслить крудами, то очевидно, что все будет неестественно и непонятно.

Answer 5

[Evgeny Svirsky]

Подключите SonataAdminBundle для админки, а для обычного вывода используйте как вы указали ProductController. Но учтите что контроллеры должны быть максимально тонкими. Там не должно содержаться бизнес-логики.

Answer 6

[Aleksei Podgaev]

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

Answer 7

[Денис Артамонов]

Модель отвечает за взаимодействие с БД
Контроллер является "прокладкой" между моделью и вью
--------------
Если у Вас "богатая" архитектура, тогда лучше разделить админу и публичную часть сайта/приложения.
Т.к. у админки будет свой бекенд+фронтенд, а у публичной части свой бекенд+фронтенд.