ASP.NET MVC и ADO.NET Entity Framework

Question

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

Answer 1

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

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

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

Answer 2

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

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

Это позволит вам использовать валидацию MVC, такую ​​как Required, Regex и т. Д. На моделях, и избегать возиться с классами Data и проходить только по Модели.

Answer 3

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

Answer 4

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

Идея заключается в том, что ваш ПОКО являются только юридическими лицами, а не EF объектами (хотя EF делает, за кулисы создания проксирования версии вашего ПОК в)