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