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

Мы используем следующие слои:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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