Zend Framework - есть ли у каждой веб-страницы свой контроллер и indexAction и view?

Question

Я хочу быть уверен, что я все настраиваю правильно.На типичном веб-сайте с 10 страницами будет ли каждая страница иметь свой собственный контроллер со своим собственным IndexAction и свою собственную папку View со своим собственным index.phtml в качестве представления?

Или у вас есть один контроллер с несколькими действиями Page1Action,Page2Action и т. Д. И иметь несколько папок view.phtml с разными именами в папке view / index?

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

Есть ли стандарт или он субъективен?

Answer 1

Ваша карта сайта будет играть важную роль в этом вопросе.Но вместо этого вот несколько примеров.

Пример 1. Flat

/foo
/bar
/baz

Возможно, вы захотите использовать отдельные контроллеры: Foo / IndexController.php, Bar / IndexController.php и Baz / IndexController.php, каждый из которых имеет метод indexAction () для передачи информации в ваше представление (еще раз отдельно).

Пример 2. НемногоПонизить сейчас

/foo/bar
/baz

Вам понадобятся только два контроллера: Foo / BarController и Baz / IndexController.Если / foo требуется целевая страница, вы должны добавить Foo / IndexController.php, чтобы быть в безопасности.Ваши действия по-прежнему indexAction ().Поскольку вы недостаточно глубоко проникли на этот третий уровень, ваши представления по-прежнему остаются index.phtml.

Пример 3. Прямая линия

/foo/bar/baz

You 'Обратитесь к контроллеру onc: Foo / BarController.php.Если вам нужны целевые страницы для / foo и / foo / bar, вам понадобится другой контроллер для / foo (Foo / IndexController) и indexAction () для обоих.С / foo / bar / baz вы теперь фактически немного изменили действие - bazAction () (внутри Foo / BarController.php).Теперь ваш вид baz.phtml.

Сводка.

Чем шире карта сайта, тем больше у вас контроллеров и меньше действий.Чем более узкая карта сайта, тем меньше контроллеров и больше действий.

Postscript.

Следует также отметить, что это также зависит от использования шаблонов маршрутизации по умолчанию.Если вы делаете что-то более изощренное в шаблонах маршрутизации, все это вылетает в окно.Иногда мы используем маршруты, чтобы сохранить количество управляемых классов.Когда у нас широкая карта сайта, можно создать несколько пользовательских маршрутов и использовать __call () в контроллере для соответствующей передачи данных.Просто еще один способ снять кожу с этой кошки.

Answer 2

Обычно вы создаете один контроллер для связанной группы действий. То, что связано, означает субъективное.

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

Если вы отделите Модель от простого компонента доступа к данным, вы сможете более разумно определить логическую группу действий Контроллера для Модели. Модель - это место, где большая часть вашего кода существует для бизнес-логики. Постоянство базы данных является лишь (необязательной) внутренней деталью Модели, чтобы сохранить состояние от запроса к запросу. Но Модель не обязательно использует базу данных. Это может быть автономно или совокупность других объектов Model.

По умолчанию каждое действие имеет собственный сценарий просмотра. Но это также только отправная точка, потому что вы можете использовать Layouts, чтобы многие скрипты View совместно использовали некоторые, если их разметка общая, и вы могли использовать View Helpers и Partials и т. Д.