Лучшие практики ASP.NET MVC с использованием EntityFramework и сопоставленных ViewModels

Я никогда раньше не работал с шаблоном проектирования MVC, а недавно я начал работать над проектом, используя ASP.NET MVC.

Я использую ActiveRecord в качестве уровня данных.

Я также использую модели представления (уникальные для каждого представления) и AutoMapper для сопоставления моих моделей представления с сущностями EntityFramework.

За несколько дней, изучая MVC, EntityFramework и читая разные статьи, я придумал следующий дизайн:

В моем решении есть веб-проект (уровень представления), который содержит представления и контроллеры.

У меня есть основной проект, в котором я определяю свои ViewModels и Services (бизнес-уровень, на котором идет вся бизнес-логика)

У меня есть проект EntityModels, в котором живут все мои объекты EF (уровень данных)

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

Из моих контроллеров (после проверок) я передаю viewModels на уровень обслуживания, где выполняется отображение и вся необходимая бизнес-логика.

Это вообще правильная конструкция?

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

Итак, может ли кто-нибудь указать, где я прав, а где нет?

заранее спасибо.


design-patterns entity-framework asp.net-mvc asp.net-mvc-viewmodel
person Burjua    schedule 12.07.2011    source источник

Ответы (2)


arrow_upward
3
arrow_downward

В целом архитектура выглядит хорошо. На мой взгляд, решение о том, где разместить модели, зависит от одного фактора.

Планируете ли вы в будущем иметь других клиентов, которым будет полезно повторно использовать эти модели представления (iPad, Android и т. Д.)?

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

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

person Craig M    schedule 12.07.2011
comment
Да, все мои модели представлений находятся в отдельной сборке под собственным пространством имен - person Burjua; 12.07.2011
comment
@jfar Время сборки, серьезно? На какой машине-динозавре вы пишете код? Без обид, но я полностью не согласен со всем вашим комментарием. Нет больше сложностей в добавлении дополнительной сборки, а время сборки настолько минимально, особенно для сборки, которая будет содержать простые модели представления, что действительно кажется, что вы пытаетесь найти причину, чтобы не согласиться с этим ответом. Если у вас нет свободных нескольких секунд во время сборки, вы делаете что-то совершенно неправильно. - person Craig M; 12.07.2011
comment
@Craig M, когда вы строите сотни раз в день, на счету каждая дополнительная секунда. Projectitus, создание проекта для каждой мелочи без веской физической причины (единственная причина для создания нового проекта, а не папки), является очень плохой практикой. Ваше замедление времени сборки для редкого шанса, что вы сэкономите 15 минут в будущем. Не стоит. - person John Farrell; 13.07.2011
comment
Предполагая, что строительство сотен раз в день равно минимум 200, это означает, что вы строите каждые 2,4 минуты в 8-часовой рабочий день или сильно преувеличиваете. Я согласен с тем, что у некоторых разработчиков есть Projectius, и я не фанат этой практики, но что-то такое же ядро ​​системы, как модели, определенно требует своей собственной сборки. - person Craig M; 13.07.2011

arrow_upward
1
arrow_downward

FWIW, я делаю то же самое, но я новичок в MVC, поэтому не уверен на 100%, что я тоже на правильном пути. Но это просто "кажется правильным", что чаще всего говорит мне, что это правильно. Единственное, что я хотел бы добавить, это то, что я использую automapper (automapper.org), что почти исключает накладные расходы, связанные с наличием слоев. Определенно проверьте это ИМО. Я должен сказать, что единственное, что не кажется на 100% правильным, - это то, что с помощью этого шаблона мы создаем множество ViewModels -> по одной на View. Я предполагаю, вы имеете в виду, что Create, Index, Update, Details для каждого объекта домена КАЖДЫЙ имеет свою собственную ViewModel? Или вы используете одну ViewModel для разных представлений? Наконец, я не верю аргументу jfars, что он создает много сложности / времени сборки. По крайней мере, он концептуально гораздо больше разделяет слои. Мне кажется, что это гораздо лучшая работа по разделению проблем с очень небольшими накладными расходами.
У меня есть несбыточная мечта о повторном использовании моделей просмотра для реализации Silverlight, но я еще не думал об этом. Но имеет смысл, что если вы хорошо поработаете над вынесением всего кода, не относящегося к пользовательскому интерфейсу, в модели представления и сервисы, то создание нового пользовательского интерфейса должно быть «тривиальным», верно? посмотрим :-)

person Joe    schedule 16.09.2011
comment
Упс, просто перечитайте свой вопрос, а вы уже используете automapper - мои извинения - person Joe; 16.09.2011