Могу ли я использовать классы Entity Framework в бизнес-уровне на отдельном уровне доступа к данным и бизнес-логики?

Question

Могу ли я использовать классы Entity Framework на бизнес-уровне на отдельном уровне доступа к данным и бизнес-логики?

РЕДАКТИРОВАТЬ: Я не думаю, что в будущем мне придется менять уровень доступа к данным из моей бизнес-логики (то есть будет SQL Server), однако я сделаю это для уровня пользовательского интерфейса. Поэтому вопрос, скорее, заключается в том, есть ли какие-либо серьезные проблемы с использованием классов EF для меня на бизнес-уровне? Похоже, было бы меньше сантехнического кода.

Answer 1

Обычно подход «наилучшей практики» будет выглядеть примерно так:

• на вашем уровне данных у вас есть EF-сущности, которые загружаются и сохраняются в базе данных

• на вашем бизнес-уровне у вас есть собственные доменные объекты (просто классы C #), которые представляют данные, с которыми ваше приложение должно работать. Они могут быть более или менее идентичны сущности уровня данных, или они могут содержать несколько «атомарных» сущностей, составляющих бизнес-объект, или они могут сильно отличаться. Чтобы устранить необходимость в большом количестве операторов назначения левой и правой руки (для перемещения значений свойств назад и вперед между объектами уровня данных и объектами бизнес-уровня), вы должны использовать такие инструменты, как AutoMapper , которые упростить настройку «сопоставлений» между похожими типами объектов и позволить легко назначать эти типы туда и обратно

• ваш слой (-ы) пользовательского интерфейса будет затем визуализировать и представлять объекты бизнес-уровня пользователю для информации и / или манипулирования

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

Конечно - это рекомендуемая лучшая практика для приложения масштаба предприятия, где вам может понадобиться поменять слой доступа к данным и т. Д. Для более простого приложения вы можете пропустить эти практики, зная что что вы делаете, и что вы «запираете» себя в EF, если вы используете сущности EF вплоть до бизнес-уровня в пользовательском интерфейсе. Если это нормально для вас и вашего сценария приложения - нет особой причины не делать этого. Объекты EF являются совершенно допустимыми объектными классами .NET - они просто наследуются от общего базового класса (EntityObject вместо object), и у них есть определенное количество «багажа», которое приходит вместе с ними. Но ничто не мешает вам использовать эти EF-сущности во всем приложении.

Answer 2

Как и на все вопросы такого рода, ответ зависит от ситуации. Если вы хотите четко разделить логику доступа к данным и бизнес-уровень, я бы сказал нет. Если это то, к чему вы стремитесь, я бы использовал шаблон репозитория и IoC для создания уровня доступа к данным, тогда вы можете заменить заглушку DAL для целей модульного тестирования, а затем получить доступ к базе данных, когда перейдете к функциональному тестированию. 1001 *

Answer 3

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

Однако, есть аргументы для того, чтобы не использовать UoW и репозиторий, главным из которых является то, что DbContext уже предоставляет вам многие из этих функций.

Я начал проект с пользовательским интерфейсом и хранилищем на уровне данных и без ссылок EF на бизнес-уровне. Когда я прогрессировал, я чувствовал, что просто делаю работу для себя, и бросил их. Вместо этого я использую доступ к контексту с бизнес-уровня, выполняю любое необходимое преобразование из DTO в бизнес-уровень POCO.

В моем сценарии я уверен, что буду придерживаться EF. Если нет, подумайте, какой подход вам подходит.