В отдельном уровне доступа к данным и бизнес-логике я могу использовать классы инфраструктуры Entity в бизнес-уровне?
EDIT: я не думаю, что мне нужно будет поменять уровень доступа к данным из моей бизнес-логики в будущем (т.е. будет SQL Server), однако я буду использовать для слоя пользовательского интерфейса. Поэтому вопрос, скорее, состоит в том, что есть серьезные проблемы с использованием классов EF для меня в бизнес-слое? Похоже, что будет меньше сантехники.
Как правило, подход "наилучшей практики" будет примерно таким:
в вашем слое данных у вас есть объекты EF, которые загружаются и сохраняются в базе данных
в вашем бизнес-слое, у вас есть свои собственные объекты домена (простые классы С#), которые представляют данные, над которыми должно работать ваше приложение. Они могут быть более или менее идентичными объекту уровня данных или могут содержать несколько "атомных" объектов для создания бизнес-объекта или они могут быть значительно разными. Чтобы облегчить потребность в множестве операторов правого присваивания слева (для перемещения значений свойств взад и вперед между объектами уровня данных и объектами бизнес-уровня), вы должны проверить инструменты, такие как AutoMapper, что позволяет легко настроить "сопоставления" между похожими типами объектов и позволить вам легко назначать эти типы назад и вперед.
ваш слой пользовательского интерфейса будет визуализировать и представлять объекты бизнес-уровня для пользователя для информации и/или манипуляции
Преимущество заключается в том, что ваша модель домена бизнес-уровня представляет собой фактические бизнес-объекты, с которыми вы работаете, и становится более или менее независимой от того, как они действительно хранятся в слое данных. Кроме того, это позволяет избежать "склеивания" вашего уровня пользовательского интерфейса с конкретной технологией доступа к данным.
Конечно, это рекомендуемая передовая практика для приложения масштаба предприятия, где вам может понадобиться изменить уровень доступа к данным и т.д. Для более простого приложения вы можете пропустить эти действия, узнать, что вы делаете, и что вы "запираете" себя в EF, если вы используете объекты EF на всем протяжении бизнес-уровня в пользовательском интерфейсе. Если это нормально с вами и вашим сценарием приложения - нет особых причин не делать этого. Объекты EF являются вполне допустимыми классами объектов .NET - они просто происходят из общего базового класса (EntityObject вместо object), и у них есть определенное количество "багажа", которое приходит. Но ничто не мешает вам использовать эти объекты EF во всем приложении.
Как и во всех вопросах такого рода, ответ зависит от этого. Если вы хотите четко разделить логику доступа к данным и бизнес-уровень, я бы сказал "нет". Если это то, к чему вы стремитесь, я бы использовал шаблон репозитория и IoC для создания уровня доступа к данным, тогда вы можете поменять местами DAL для тестирования модулей и затем получить доступ к базе данных, когда вы перейдете к функциональному тестированию.
Если вам нужно изменить способ доступа к базе данных без необходимости переписывать много кода, лучше сохранить EF из бизнес-уровня. Вы можете использовать Модели работы и шаблоны хранилища для достижения этого; доступ ко всем функциям уровня данных через интерфейсы. Если вы выбросите EF, интерфейсы останутся прежними, вы просто измените классы реализации.
Однако есть аргументы в пользу использования UoW и репозитория, главным из которых является то, что DbContext уже предоставляет вам многие из этих функций.
Я начал проект с UoI и репозитория на уровне данных и без ссылок EF на бизнес-уровне. По мере того как я прогрессировал, я чувствовал, что я просто делаю работу для себя, и бросил их. Вместо этого я использую доступ к контексту из бизнес-уровня, выполняю любое преобразование, которое мне нужно, от DTO до уровня POCO для бизнеса.
В моем сценарии я уверен, что придерживаюсь EF. Если вы этого не сделаете, подумайте, какой подход вам подходит.