Как определить свои контроллеры в MVC?

Я использую один контроллер для каждой «проблемной области». Это произвольно, и обычно это немного большая категория, основанная на модели предметной области, которая включает несколько объектов.

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

В Ruby on Rails (и других веб-фреймворках MVC) контроллеры сопоставляются с URL-адресами через какую-то конфигурацию маршрутизации.

Например, / mysection / view / 2 обычно отображается на controller = mysection, method = view, id = 2 (в Rails это отображение по умолчанию в ./config/routes.rb: map.connect ':controller/:action/:id')

Когда вы говорите, что у вас есть «пользовательский контроллер и множество методов для управления этим объектом, например, user / add, user / edit, user / delete, user / profile», я думаю, вы имеете в виду модель - так что у вас будет UserModel.create (), UserModel.find () и т. д. Затем контроллер будет использовать модель для редактирования данных - фактический контроллер должен иметь только несколько строк кода, вызывающих модель (скажем, @myuser = User.find(id)), и несколько методов, которые сопоставлены с URL-адреса (например, /usercontroller/new, /usercontroller/edit, /usercontroller/view)

Это описание было в значительной степени специфичным для Rails, но большинство фреймворков PHP будут очень похожи - я знаю, что CodeIgniter использует почти такую ​​же компоновку.

Контроллеры больше похожи на часть кода, из которой запускаются вызовы. В хорошо инкапсулированном коде методы, которые изменяют модель, присутствуют близко к модели (в том же объекте предметной области). Однако точка вызова отделена (не является частью одного и того же объекта домена).

Некоторые фреймворки, такие как struts, предоставляют настраиваемые контроллеры (с использованием xml). Существует также концепция Front Controller, в которой универсальный контроллер действует как делегатор верхнего уровня. Мы можем использовать этот фронт-контроллер для обработки тривиальных сопоставлений (не только для домена).

При создании контроллеров я обычно думаю о том, что видит пользователь и что было бы интуитивно понятно для пользователя, поскольку контроллеры отображаются на URL-адреса.

В вашем примере имеет смысл иметь все связанные с пользователем страницы в формате / user / edit, / user / profile и т. д., Как вы сказали. Однако, если бы я был вами, у меня не было бы отдельной страницы входа для администраторов, я бы использовал то же представление входа в систему и обрабатывал бы бит администратора в другом месте.

Короче говоря, обычно я делаю контроллер для каждой ключевой концепции, которую пользователь будет иметь в виду при использовании сайта. Поэтому, если бы пользователи на сайте могли добавлять / удалять друзей, я бы рассматривал это как отдельную концепцию (а не как часть концепции пользователя). Так что у меня был бы контроллер друзей с такими функциями, как друзья / добавить, друзья / список, друзья / удалить и т. д.