В отдельном доступе к данным и слое бизнес-логики, я могу использовать классы платформы Объекта в бизнес-слое?
В отдельном доступе к данным и слое бизнес-логики, я могу использовать классы платформы Объекта в бизнес-слое?
Править: Я не думаю, что должен буду выгрузить уровень доступа к данным от своей бизнес-логики в будущем (т.е. будет SQL Server), однако я буду для уровня UI. Поэтому вопрос более предназначен, чтобы быть, там какие-либо главные проблемы с использованием классов EF для меня в бизнес-слое? Походит там меньше установил бы вертикально код.
2 ответа
Обычно "передовой" подход выглядит примерно так:
на уровне данных у вас есть объекты EF, которые загружаются и сохраняются Вернувшись к базе данных
на уровне Business, у вас есть собственные объекты домена (просто классы C #), которые представляют данные, с которыми ваше приложение должно работать. Они могут быть более или менее идентичными сущности уровня данных, или они могут содержать несколько «атомарных» сущностей, составляющих бизнес-объект, или они могут сильно отличаться.Чтобы избавиться от необходимости использовать множество операторов присваивания слева-справа (для перемещения значений свойств между сущностями уровня данных и объектами бизнес-уровня), вам следует воспользоваться такими инструментами, как AutoMapper , которые упростить настройку «сопоставлений» между схожими типами объектов и позволит вам легко назначать эти типы взад и вперед
. Затем ваш слой (и) пользовательского интерфейса будет визуализировать и представлять объекты бизнес-уровня пользователю для информации и / или манипуляция
Преимущество состоит в том, что ваша модель предметной области бизнес-уровня представляет реальные бизнес-объекты, с которыми вы работаете, и становится более или менее независимой от того, как они на самом деле хранятся на уровне данных. Кроме того, это позволяет избежать «привязки» уровня пользовательского интерфейса к конкретной технологии доступа к данным.
Конечно - это рекомендуемый передовой метод для приложения корпоративного масштаба, где вам может потребоваться поменять уровень доступа к данным и т. Д. Для более простого приложения вы можете пропустить эти методы, зная , что вы делаете, и что вы «блокируете» себя в EF, если используете EF-сущности на всем протяжении бизнес-уровня в пользовательском интерфейсе. Если вас устраивает сценарий вашего приложения - нет особых причин не делать этого. Сущности EF - это совершенно допустимые классы объектов .NET - они просто являются производными от общего базового класса ( EntityObject вместо объекта ), и у них есть определенный объем «багажа», который приходит вместе с ними. Но ничто не мешает вам использовать эти объекты EF во всем приложении.
Как и на все вопросы такого рода, ответ - зависит от ситуации. Если вы хотите четко разделить логику доступа к данным и бизнес-слой, я бы ответил отрицательно. Если это то, к чему вы стремитесь, я бы использовал паттерн репозитория и IoC для создания уровня доступа к данным, затем вы можете установить заглушку DAL для целей модульного тестирования, а затем добавить доступ к базе данных, когда вы перейдете к функциональному тестированию.