Один контроллер на страницу или много страниц в одном контроллере?


16

Я просто хотел получить совет относительно того, как вести себя в MVC. Я использую codeigniter и мне было интересно, лучше ли иметь один контроллер на страницу для веб-сайта или один контроллер для всех страниц?

Допустим, у меня есть простой веб-сайт, на котором вы можете посетить домашнюю страницу, войти в систему, создать учетную запись и связаться с администратором.

  1. Было бы лучше иметь эти контроллеры: внешний интерфейс (индекс), логин, учетную запись, контакт ИЛИ с одним контроллером, называемым внешним интерфейсом, или что-то еще с такими действиями, как вход в систему, createAccount, контакт?

  2. Когда вы знаете, лучше ли использовать один контроллер в ситуации?


Я всегда жил вероучением: Один Контролер, чтобы Управлять ими всеми, и в Тьме, Привязать их. (Не совсем, но мне нравится, как это звучит. :-)
Питер Роуэлл

Ответы:


17

Лучше иметь контроллер для каждой логической единицы, например AccountController (вход в систему, регистрация), PagesController (дом, контакт), Backend -> PagesController (создание, редактирование, удаление), UsersController (создание, редактирование, удаление) и так далее.


Как бы вы представили сайт с тезисами областей: дом, логин, аккаунт, контакт. Будете ли вы использовать 2 контроллера, как ваш пример? если вы идете на localhost / он открывает homecontroller, то если вы идете на localhost / contact в теории, не должен ли он пойти на контроллер контроллера? а что вы подразумеваете под бэкендом?
Рушино

Это зависит от того, какова структура страниц и сколько у вас страниц. Я сделаю HomeController (дом, контакт) или PagesController (дом, контакт ИЛИ детали (id)). Например, в ASP.NET MVC у вас есть HomeController по умолчанию со страницей Home и About.
Сантас

Мне нравится этот метод. Также ClientController (или как вы хотите это называть) для действий, вызываемых через Jquery.Ajax, которые не относятся к какой-либо конкретной части вашего приложения. то есть можно использовать с любой из ваших точек зрения
Крис

Кажется, правильный ответ для меня. CodeIgniter принимает подкаталоги для контроллеров, которые позволяют разделить контроллеры на зоны, чтобы я мог получить два контроллера страниц (по одному на зону). Благодарность!
Рушино

Но разве у вас не получится несколько больших контроллеров, хотя все действия относительно? Или это не проблема?
Малыш Даймонд

4

@Rushino У вас есть два «приложения» здесь - интерфейс (для читателей) и сервер (для администраторов). Для каждой группы функций у вас есть контроллер.

Вход в систему - это такая группа, которая включает в себя создание формы HTML (поля, вызывающие представление) и обработку формы (проверка, связывающаяся с моделью). Таким образом, 'login' - это контроллер с двумя действиями - generateForm и handleForm.

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

Для пользователей - если пользователи могут зарегистрироваться самостоятельно, им потребуется контроллер внешнего интерфейса, но если нет, все, что связано с пользователями, просто отправляется в бэкэнд.

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

В итоге это выглядит так:

Frontend
  Pages
    View, Handle
  Login
    View, Handle
  Users
    Register (note that the handler can be the same as 'create' on the backend)
  Contact
    View
    Handle

Backend
  Users
    Create, Delete, Edit, Update, View
  Pages
    Create, Delete, Edit, Update, View

Подождите .. вы говорите, что один раздел представляет собой одно приложение? интересный способ сделать это (и, вероятно, способ сделать это). Интересно, будет ли кодигнитор делать это так ... проверим. Я должен быть уверен, что вы можете переходить из одного приложения в другое, не нарушая ни сеанса, ни состояния соединения.
Рушино,

1
@Rushino CodeIgniter может сделать это следующим образом - вы можете поместить папки в каталог Controllers. Различие между «приложениями» не на уровне базы данных / модели, а на уровне контроллера / представления. Причина разделения заключается в том, что ваш бэкэнд делает совершенно разные вещи, часто с совершенно другим дизайном. Это помогает с безопасностью, потому что вы можете ограничить IP-адрес всего внутреннего каталога. И это помогает в разработке, потому что вы можете работать с бэкэндом, не влияя на внешний интерфейс.
Дэн Блоу

2

Я думаю, что вы должны использовать контроллер для каждого подразделения, например OrdersController для всех операций, связанных с заказами и тому подобное. Мне известно, что в этом случае контроллеры получают ОГРОМНОЕ, но мы все еще можем использовать вспомогательные классы для делегирования таких вещей, как инициализация модели и частичные классы, для распределения действий в отдельных файлах.

Например, у меня может быть OrdersControllerCreate.cs and OrdersController файлы List.cs для класса OrdersController, каждый с соответствующим набором Actions. Делает вещи намного чище и сохраняет централизованные операции с заказами в одном классе контроллеров.

Просто мои 2 цента.


0

Я думаю, что вы могли бы использовать другой подход:

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

Это не моя идея, но Symfony Framework работает таким образом, поэтому я могу сказать вам, что по моему опыту это действительно хороший и элегантный способ реализации внешнего интерфейса.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.