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

Я довольно новичок в MVC, исходя из фона php, где я проектировал представление и создавал страницы, когда мне нужно было что-то вроде формы входа. У меня был бы файл с именем login. Это было отстойно только тогда, когда мне нужна была новая форма входа для входа в систему другого типа пользователя. Скажи админ. Затем мне пришлось бы создать новую страницу с именем login-admin.php или что-то в этом роде.

Недавно я начал изучать MVC и особенно фреймворки, и самая большая проблема, с которой я столкнулся, это определить, как именно вы придумываете свои контроллеры. Мне сказали либо использовать один контроллер для каждого маршрута файла представления, либо получить свои контроллеры на основе объектов вашего домена.

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

Итак, как лучше всего определить, какими будут ваши контроллеры???


php controller model-view-controller
person Community    schedule 08.10.2008    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

person Troy Howard    schedule 08.10.2008

arrow_upward
2
arrow_downward

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

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

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

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

person dbr    schedule 08.10.2008

arrow_upward
1
arrow_downward

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

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

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

person Murat Ayfer    schedule 08.10.2008

arrow_upward
0
arrow_downward

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

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

person questzen    schedule 08.10.2008