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

Question

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

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

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

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

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

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

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

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

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

Правильно ли это оформление?

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

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

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

Answer 1

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

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

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

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

Answer 2

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