Лучшие практики для разделения кода модели на логические части в MVC?Который лучший?

Question

Я новичок в MVC, но из того, что я узнал до сих пор (например, здесь , ScottGu), следует стремиться к "худым контроллерам", а не к "толстым".
Добавьте к этому тот факт, что представления по своей сути тонкие, и вы получите много кода в вашей модели.

Итак, мой вопрос: как разделить код в вашей модели на различные логические части, чтобы уменьшить сложность?
Используете ли вы Data Access Layer и Business Logic Layer внутри самой модели (которая, я думаю, по-прежнему содержала бы много кода), или есть лучшие способы сделать это?

Спасибо.

Answer 1

Используемые нами слои:

• Просмотр (со строго типизированными моделями просмотра)
• Контроллер
• Просмотр модели Service
• Бизнес-услуги
• Репозитории
• (EF) Контексты

Представления - настолько тонкие, насколько это возможно - без логики - просто отображать

Просмотр моделей - С строгой типизациейper view - не содержит сущностей, а только те поля, которые нам нужны в любом представлении.

Controller - только маршрутизация и вызовы в VMS.Обрабатывает исключения, всплывающие с нижних уровней, путем маршрутизации на страницы ошибок.

View Model Services - создает и распаковывает модели представления в объекты EF.Нет логики доступа к данным.Один VMS на контроллер.Активно использует AutoMapper для передачи данных модели представления в сущности.

Бизнес-сервисы - основная точка доступа к данным.Одна БС на контроллер.Использует столько хранилищ, сколько требуется для выполнения своей работы.Контроллер объема транзакций здесь.VMS делает один вызов к BS - который оборачивает все необходимые вызовы DB в одну транзакцию, если требуется.В будущем мы ожидаем, что БС будет обращаться к внешним службам.

Репозитории - один объект для каждого (верхнего уровня) - выполняет все операции CRUD для группы объектов.Наши объекты - это большие, сложные графы объектов - поэтому мы обрабатываем самый верхний родительский элемент для каждого хранилища.

Контексты - тонкие обертки вокруг сгенерированных EF контекстов, так что они могут меня высмеивать.

С точки зренияMVC - часть модели состоит из всего, что находится под контроллером.

Answer 2

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

Когда мне придется обрабатывать объекты, которые отказываются аккуратно отображаться в одну таблицу в базе данных, я создаю фасад или составной объект, через который может взаимодействовать бизнес-логика. Это гарантирует, что даже при том, что Business Logic рассматривает их как единое целое, уровень обслуживания данных по-прежнему видит их как отдельные и может обновлять только те, которые в этом нуждаются.

Я рекомендую эту статью о Сопоставлении объектов с реляционной моделью , чтобы начать работу.

Answer 3

Вот как я обычно делю вещи и рекомендую делить вещи:

• Модель: представляет информацию.Никогда не должен содержать код, связанный с рендерингом.Не должен содержать код для публикации / подписки на обновления.Не должен содержать код для чтения / записи.

• Ввод / вывод модели: код, который читает / записывает модель на / с диска, в сеть, SQL или в другое хранилище резервных копий, как правило, должен быть отдельнымиз самого объекта модели, чтобы разрешить альтернативное хранение.

• Инфраструктура контроллера: обеспечивает оболочку поверх модели, которая добавляет поведение публикации / подписки в модель (т. е. сигнализирует об изменении уведомления)события при изменении модели).

• Контроллер: создает модель и представление, загружает модель из хранилища, регистрирует обработчики на модели для обновления представления при изменении.Регистрирует обработчики в представлении, чтобы обновить модель для действий вида и сохранить / сохранить модель при вызове действий сохранения.

• Представление: один или несколько компонентов, отображающих модель.

Answer 4

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