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

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

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

Спасибо.

Ответы на вопрос(4)

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

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

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

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

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

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

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

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

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

 Oren A29 сент. 2010 г., 18:42
Спасибо за вклад, теперь у меня есть еще одна тема для чтения о .. (-:
Решение Вопроса

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

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

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

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

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

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

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

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

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

 JoseMarmolejos24 сент. 2010 г., 02:21
Я придерживаюсь аналогичного базового дизайна, я просто пропускаю репозитории и слои сервисов viewmodel.

Ваш ответ на вопрос