Сколько действий на контроллер в MVC
Я знаю, что название вопроса расплывчато, но я не мог придумать ничего более чистого. (И хотя это может показаться вопросом ZF, на самом деле это просто вопрос php MVC.)
Недавно я перенес проект с ZF2 на ZF3. Основным отличием была необходимость внедрения зависимостей в каждую модель и контроллер. Поскольку теперь я ввел все зависимости вместо того, чтобы вызывать их с помощью serviceLocator (который лениво загружает службу), у меня возникла пара вопросов.
Несколько контроллеров теперь кажутся действительно раздутыми и создают экземпляры служб, которыми они не будут пользоваться. Просто потому, что другому действию нужна служба, теперь весь контроллер создает экземпляр службы. Несмотря на то, что создание экземпляра службы не так сильно требует производительности, это все равно кажется пустой тратой.
У меня вопрос, и это в основном мой вопрос с тех пор, как я начал работать с MVC, насколько конкретно вы бы сделали контроллер? Сколько действий на контроллер? Или, может быть, в данном случае: сколько сервисов на контроллер?
Я сейчас даже подумываю разделить каждый контроллер, чтобы у всех действий был свой контроллер. Это хорошая / плохая идея?
Есть предположения?
Одно диспетчерское действие для каждого контроллера является разумным, но если вас беспокоят накладные расходы на загрузку сервисов, вы можете захотеть загрузить их лениво: docs.zendframework.com/zend-servicemanager/lazy-services
Ответы 1
Я лично придерживаюсь того, чтобы Контроллер был сосредоточен на одном действии. Но он должен иметь возможность делать / вызывать все необходимое для завершения действия.
Например, у вас есть сущность продукта. Для базового CRUD (я использую iCRUD, почему бы и нет?: P) я бы создал 5 контроллеров: Index, Add, View, Edit, Delete (семантика, независимо от того, используете ли вы Add / Create, View / Read и т. д.).
Самый большой из них - Edit, который должен «получить» существующий продукт, загрузить его в форму и вернуть его только для настройки страницы редактирования. При POST данных ему нужно будет получить существующий Продукт, загрузить его в форму, получить данные запроса и загрузить их в форму, проверить, подготовить к хранению, сохранить и вернуть ответ.
Но я предпочитаю, чтобы он мог делать все, но сосредоточился на этом действии.
Конечно, вы можете иметь все (i) действия CRUD в одном контроллере и при этом правильно применять MVC. Лично я считаю более чистым разделить их. В любом случае из пространства имен вы сможете определить, для какого класса вы смотрите.
Пример из проекта ниже:
На мой взгляд, ясно, что здесь мы смотрим на модуль User, подпространство имен Controller, сфокусированное на объекте User. (В этом модуле есть родственники объекта User: Route, Role и т. д.)
Надо сказать, у него есть как плюсы, так и минусы.
Плюсы:
- Чисто и ясно, где вам нужно быть для чего-то
- Разделение проблем
- Довольно СУХОЙ (Не повторяйся)
- Простые в повторном использовании контроллеры действий для разных предметов (например, создать более абстрактный ViewController и реализовать для каждой темы: продукт, пользователь, адрес и т. д.)
Минусы:
- Достаточно СУХОЙ (не повторяйтесь) (посмотрите, что я там сделал? Это нужно делать с предварительной загрузкой форм и т. д.)
- Дополнительная конфигурация в таких фреймворках, как Zend Framework 3 (дополнительные комбинации Контроллер / Завод для регистрации)
- Настройка занимает больше времени, рефакторинг - это «больше»
Контроллер - это такой же класс, как и любой другой. В более общем смысле, всякий раз, когда вы обнаруживаете, что думаете, что «этот класс действительно большой и делает много разных вещей», вы, вероятно, захотите реорганизовать его на более мелкие компоненты.