Веб-сайт www.halifax.co.uk предлагает различные категории продуктов, такие как ипотечные кредиты, сбережения. Ипотечные и сберегательные продукты будут хранить разные поля данных. Это не соответствует наличию одного контроллера продуктов, который будет использоваться в большинстве случаев. Контроллер отдельных продуктов или контроллер для каждой категории продуктов?Создание приложения ASP.NET MVC с различными категориями продуктов
Простой ответ заключается в том, что это зависит от количества «бизнес-логики», которое несет каждая категория продукта. Вы должны посмотреть на свою модель домена и посмотреть, что действительно означает ваши категории продуктов в вашем домене.
В случае, например, на аукционе, основное внимание уделяется продукту. Категория действительно представляет собой только иерархию строк, которые можно использовать для маркировки продукта. Поскольку доступные категории также растут и сокращаются изо дня в день, создание контроллера для каждой категории создает кошмар для обслуживания.
В случае банковского сайта основное внимание уделяется каждой отдельной категории продуктов, например «Сберегательный счет», «Кредитные карты» и т. Д. Существует так много разницы между этими разными категориями, что имеет смысл создавать отдельные контроллеры для них.
С одной стороны каждая из этих категорий продуктов может иметь различное количество и тип полей. Тогда простой подход состоит в том, чтобы иметь разные контроллеры, каждый из которых ведет к различным представлениям, строго типизированным для разных моделей. «Ипотека» будет одной моделью со своими собственными полями и ее собственным Индексом, Детали, Редактировать и Удалить Виды и MortgageController. Аналогично для Сбережений. Это самый простой подход к приложениям ASP.NET MVC с использованием строго типизированных представлений. Обратите внимание, что даже в этом случае дублирование может быть устранено или сведено к минимуму путем тщательного ухода и рефакторинга контроллеров (и моделей, и видов, конечно).
Однако я бы рекомендовал проанализировать поведение каждого из этих типов продуктов. Если на самом деле все они ведут себя одинаково, есть способы обойти проблему с разным количеством или типом полей. Например, все модели разных типов могут наследовать общий базовый класс или реализовать общий интерфейс (последний может быть лучшим из двух решений, но трудно сказать, следует ли в этом случае предпочесть наследование или состав). Это всего лишь два варианта для разработки «слабо типизированных» представлений и контроллеров.
Я не могу сказать, следует ли вам идти так или иначе из краткого описания, которое вы дали, но я убежден, что ответ заключается в поведении моделей (а не их структуре). В моем личном опыте модели, которые ведут себя одинаково (например: все они выставляют одни и те же операции CRUD), должны обрабатываться одним образом, но поведенческие различия (например: различные бизнес-правила, которые должны быть проверены, когда модель определенного типа сохранены) необходимо обрабатывать по отдельности. HTH