В MVC, как вы структурируете #Controllers по отношению к представлениям, моделям и маршрутизации? - PullRequest
2 голосов
/ 11 апреля 2011

У меня есть вопрос, касающийся структуры приложения MVC. Предположим, мы должны реализовать веб-приложение, состоящее из нескольких модулей, таких как корзина покупок, браузер магазина (конечный пользователь), менеджер магазина (администратор) и так далее.

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

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

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

Спасибо

Francesco

Ответы [ 2 ]

2 голосов
/ 11 апреля 2011

Конечно, можно создать один контроллер и использовать маршрутизацию для отправки запросов методу действия конкретного контроллера.[...]

Другой подход заключается в использовании одного контроллера для каждого раздела приложения, [...]

Вы пропускаете третью альтернативу, которая является наиболее распространеннойодин.В общем случае вы должны иметь один контроллер на ресурс . ресурс - это модель, которая является публично доступной.В вашем конкретном приложении витрины ресурсов могут быть такие вещи, как Products, Orders, Customers и т. Д.

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

1 голос
/ 11 апреля 2011

Вы должны стараться следовать REST , насколько это возможно

В основном - это означает контроллер для каждой «коллекции» (вашей сущности).

Если ваши контролеры будутбыть RESTful, другие части (маршрутизация, представления) будут соответствовать друг другу соответственно.

...