ASP.NET MVC и ADO.NET Entity Framework

Question

У меня есть проблема, которую я не могу решить без какого-либо совета. Я занимаюсь разработкой приложения ASP.NET MVC и использую ADO.NET EF для подключения к базе данных. Моя проблема в том, что я не знаю, должна ли бизнес-логика моего приложения использовать сущности, созданные EF, или мне нужно создать еще один уровень абстракции и отделить сущности EF от моих объектов бизнес-логики (и разработать некоторые конвертеры между этими типами объектов). Или, может быть, я совершенно не прав, и я должен сделать это по-другому? Как? Какое решение будет наилучшей практикой?

Answer 1

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

Чтобы прояснить это, я не предлагаю против уровней абстракции. Их использование очень сильно зависит от ваших конкретных требований.

Я бы начал с простой архитектуры и добавлял слои по мере необходимости для обеспечения возможности тестирования и обслуживания. Текущая версия Entity Framework (4.1 на момент написания этой статьи) позволяет работать с POCOs , а DbContext во многом напоминает Repository и Unit Работа шаблонов. Эти готовые функции в большинстве случаев могут быть достаточными для начала.

Answer 2

Здесь вступают в игру POCO. Вы можете генерировать общие POCO из вашей модели данных и использовать их на своем бизнес-уровне. EF создаст POCO и отследит их.

Идея заключается в том, что ваши POCO - это просто сущности, а не объекты EF (хотя EF скрытно создает прокси-версии ваших POCO)

Answer 3

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

Answer 4

Я справился с подобными ситуациями, создав отдельные проекты для классов Data и Model.

Классы данных будут сгенерированы вашей моделью ADO.net, тогда вы можете использовать шаблон Repository для подключения к контексту ADO.net, извлечения классов данных и использования чего-то вроде http://automapper.codeplex.com/ для сопоставления класса данных с бизнес-моделью.

Это позволит вам использовать в моделях проверку MVC, такую ​​как Required, Regex и т. Д., И не вмешиваться в классы данных и толькораздайте модели.