Понимание контроллеров в MVC

Контроллер формирует границу системы, которая является http-интерфейсом вашего приложения. Он принимает запрос, запускает обработку запроса и возвращает результат клиенту.

Вы можете поместить все действия, принадлежащие определённому классу доменных объектов, в один контроллер. Это приведет к указанному шаблону URL /$контроллер/$экшен. Я бы предложил использовать REST. При использовании REST вы думаете не о "контроллерах" и "экшенах", а о "ресурсах". Каждый ресурс имеет общий набор методов, а именно DELETE, GET, POST и PUT. Эти методы являются HTTP глаголами. У вас будет больше ресурсов, чем у контроллеров с не-REST подходом, но общее количество экшенов будет одинаковым.

В вашем примере одним ресурсом будут "вопросы", которые будут представлять собой список всех вопросов. Для создания нового вопроса клиент посылал бы http-запрос типа "POST /questions $formdata". Новый объект вопроса будет создан и добавлен в список. Клиент получит перенаправление на созданный вопрос "перенаправить /questions/4128", а затем загрузит его с помощью "GET /question/4128".

REST вкратце:

• каждый ресурс имеет глобальный id (URL)
• каждый ресурс имеет общий набор методов (DELETE, GET, POST, PUT)
• приложение REST не имеет статуса (нет состояния сеанса между запросами)

Преимущества:

• просто
• унифицировано; легко понятно для новых разработчиков, просто в использовании для клиентов-разработчиков
• удобно с несколькими клиентами, такими как браузеры, агрегаторы лент, веб-сервисы . ...
• REST использует всю мощь http без накладных расходов (по сравнению с веб-сервисами SOAP)

Давайте распустим свой вопрос в два:

1. Какова роль контроллера в MVC вкус, предлагаемый Monorail и ASP.NET MVC?
2. Как сопоставления URL относятся к применительному действиям?

Мои взять 1:

Как этот тип вопроса поддается многим религиозным ответам, я считаю, что Нет «Один из способов править их всех». Сейчас в монорельсе и ASP.NET MVC (а также ROR конечно), контроллер - это просто сбор акций. Правильный вопрос тогда: «Какова роль действий»?

В моей книге (неписанная книга монораил-в действии ... :)), роль действия состоит в том, чтобы отделить доменную модель от презентации , как с точки зрения структур данных, так и в опасении. Все, что специализируется на том факте, что интерфейс с доменом проходит через веб-запросы, является ответственностью слоя контроллера. Это включает в себя связывание и преобразование данных, связанные с аутентификацией (но не авторизации) и принятия решений для шаблонов просмотра. Таким образом, действие будет принимать параметры из входящего запроса (в Интернете нет . Концерн домена), свяжите их к значимым данным, которые можно отправить домену в качестве запроса или команды, на языке домена , без печенья, формы, квитанции и других «веб-материалов». Он также при просмотре данных будет преобразовать доменные объекты, которые возвращаются из модели, в модель просмотра, что в той же книге, упомянутой ранее, это модель, разделенная с моделью домена, и отвечает за поставку Шаблон со всеми данными и решением, принимающим решение. Итак, например., Вид не должен просить , если (view.user.isadmin) и визуализация кнопки «редактирование», но вместо этого действие контроллера сделает этот вопрос и предоставила вид с помощью Решение, для просмотра, чтобы просить , если (View.shouldRenderededButton)

Итак, слой контроллеров разделяет веб-концерн от проблем домена.

Что касается вопроса нет. 2:

Идея отображения URL URL в качестве контроллера / действия является просто следствием принятия подхода «Конвенция о конфигурации». Значение, для разработчиков было бы легче работать с схемой, которая распространена в разных веб-приложениях. Сказав это, он не написан в камне, и, как и любая конвенция, это основа для адаптации. Поэтому, если вы строите веб-сайт, и менеджер продукта просит «красивые URL», то вы просто настроили свой двигатель маршрутизации соответственно.