Использование объектов Entity Framework как бизнес-объектов?

Ответ 1

Я использую EF таким образом, и одна приятная особенность заключается в том, что сгенерированные объекты являются частичными классами, что позволяет им расширяться таким образом, чтобы они были защищены от проблем с регенерацией.

Также рассмотрите эту ссылку в MSDN, в которой описываются некоторые общие сценарии использования с EF в отношении бизнес-логики.

Ответ 2

Во-первых, с просмотрами вопросов 11k на момент написания этой статьи, я немного удивлен отсутствием ответов и со всем уважением, качеством ответов, учитывая довольно простой вопрос.

Итак, теперь, когда я немного отклонился, я хотел бы затронуть этот вопрос (-ы), потому что я думаю, что сегодня он применяется еще и к недавней версии Entity Framework Code-First.

"Использование сущностей Entity Framework как бизнес-объекты?"

Несколько пунктов разъяснения, прежде чем я начал:

• Когда вы говорите "бизнес-объекты", у меня создается впечатление, что эти объекты, на которые вы ссылаетесь, содержат правила или логику, начиная от, например, простой проверки (т.е. требуемых полей) до более сложной логики (т.е. обработка налог на выписку).

• Я не думаю, что я могу ответить на ваш следующий вопрос относительно WCF. Причина этого состоит в том, что я собираюсь объективно ответить на ваши вопросы об EF как бизнес-объектах, которые затем субъективно заставили бы меня занять позицию, доказывающую противоречивость моей попытки искренне и объективно ответить на первый вопрос.

  /li >

Тем не менее, на ваш EF в качестве вопросов бизнес-объектов...

"Я использую модуль отображения объектов Entity Framework O/R от Microsoft и использования объекта классов (сгенерированные классы, которые сопоставлены с объектами БД) как бизнес объекты. Это нормально?"

Извините, здесь нет правильного или неправильного ответа. Это зависит от вашей цели и того, что вы считаете самым разумным проектом, в то же время полностью понимая преимущества и недостатки этого.

"Пожалуйста, укажите свои минусы или плюсы"

Я рад, что ты спросил! Я буду рад ответить, и я надеюсь, что, учитывая плюсы и минусы, вы можете принять обоснованное решение относительно того, считаете ли вы, что использование EF для ваших бизнес-объектов является "ОК". Как правило, Id разрывает плюсы и минусы, позволяя легко "переваривать", однако я не думаю, что это уместно здесь, потому что я думаю, что мы несем несправедливость по отношению к такой очень интересной теме, которая также близка и близка моему сердцу.

Прежде всего, позвольте мне говорить технически на мгновение... Вы можете использовать объекты EF в качестве своих бизнес-объектов, и ничего технически не мешает вам это делать. По сути, EF Code-First (CF) делает это невероятно простым, позволяя создавать POCOs и давать вам возможность применять аннотации данных для простой проверки, а также для реализации IValidatableObject для более сложной проверки. Довольно круто, а?

В этом и заключается суть дискуссии.

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

• Экран для редактирования пользователя
• Элемент управления для отображения только для чтения подмножества информации пользователя

Если вы используете EF (любой вкус) или любой ORM в этом отношении, вы можете тяготеть к использованию одного и того же объекта "Пользователь" для обработки возможности сохранения пользователя, а также для извлечения пользователя для поднабора, только поля. Возможно, вы делаете это по одной из нескольких причин:

• Как и многие разработчики, у нас есть это семя, посаженное в наши мозги во время обучения. "Укрепление кода" имеет первостепенное значение или, возможно, более известен как DRY - Dont Repeat Yourself, и поэтому вы можете посмотреть на дублирование кода, например, в отрицательном контексте.
• ORM, такие как EF 4.1, имеют технические ограничения (и хакерские обходы), такие как отображение нескольких POCOs/объектов в одну и ту же таблицу базы данных, тем самым вынуждая вас независимо от ваших убеждений.
• Это быстрый и простой способ запуска и запуска приложения
• Это "чувствует", как правильная вещь.

Есть преимущества и недостатки этого, и вы можете смотреть на это либо положительно, либо отрицательно, в зависимости от вашего мнения.

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

И я полагаю, если вы верите в нормализацию поведения над кодом, чем потерпели неудачу. Сохраняя код, вы жертвовали проектированием объектов своими обязанностями, что потенциально затрудняло управление и впоследствии увеличивало затраты на поддержание.

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

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

Итак, что все это связано с тем, следует ли мне использовать EF для представления моих бизнес-объектов?

Ну... Хотя это технически возможно, существуют разные философии (некоторые хорошие, некоторые плохие) о том, следует ли использовать EF или любой ORM для представления ваших бизнес-объектов. Я дал обзор, направленный на сердце этих философий выше, но они описаны гораздо более подробно такими людьми, как Рокки Лхотка и Мартин Фаулер.

Направленное вами направление, скорее всего, будет зависеть от приложения и от философского взгляда, может зависеть от того, насколько вы идеалист или прагматик. Тем не менее, я не подразумеваю, что один из идеалистов или прагматиков коррелирует либо с использованием EF для бизнес-объектов, либо нет - он просто повлияет на ваш подход к этому.

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

Надеюсь, что это поможет.

Отключить, чтобы ответить на вопрос о том, смехотворно ли незнание персистентности с ORM с учетом цели, стоящей за ней, - управлять данными.:-) Извините, я не смог сопротивляться!

Ответ 3

Структура Entity была разработана для объектов сущности, которые будут использоваться в качестве бизнес-объектов, но вы должны иметь в виду, что бизнес-объекты будут привязаны к технологии O/R, а также к модели EDM. В EF 1.0 не было поддержки Persistence- незнание, но поддержка была добавлена ​​в 4.0. Вы можете реализовать интерфейсы, если вы не хотите использовать какой-либо из их базовых классов.

Начиная с .NET 3.5 SP1, они также должны использоваться как paramater и возвращаемые типы в методах службы WCF без какого-либо дополнительного кода.

Ответ 4

По моему опыту мы использовали объекты EF в бизнес-слое нашего приложения, но когда мы переходим на уровень представления через наш сервисный уровень WCF, мы создадим объекты вида из объектов EF.

В нашем случае только представление передается на уровень представления. Мы делаем это, чтобы контролировать, как представлены данные, и применять защитную проверку для данных, поступающих с уровня представления.

В случае ueing объектов EF в транзакции WCF вы потеряете контекст объекта, связанный с объектом EF. В CodePlex есть некоторые усилия, которые пытаются помочь в этом, но я не поддерживал их усилия.

Ответ 5

Два ограничения, которые должны быть в курсе того, с которыми я столкнулся, заключаются в следующем:

• Унаследованные объекты не могут иметь Свойства навигации - т.е. если у вас есть класс "человек", а затем "клиент" и "поставщик", то эти клиенты и поставщики не имеют свойств навигации.

• Методы и расчетные поля (что-либо в частичных классах) не передаются через службы данных ADO.Net - если вы также используете службы данных ADO.Net, все, что вы расширяете, объекты Entity Framework в частичных классах не будут передаваться через службы данных ADO.Net.

Как правило, это не объекты show-stopper (для свойств навигации мы пока не используем наследование в инфраструктуре сущности), но может быть что-то интересное для вас. Я надеюсь, что в будущем выпуске будут доступны оба этих элемента.

Ответ 6

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

Я бы не рекомендовал использовать объекты EF в качестве объектов DataContract для WCF, так как вы очень сильно привязывали бы реализацию объектов сущности к клиентам веб-сервисов, изменение будет трудно сделать в будущем, тем сложнее, чем больше клиентов вы планируете по наличию.

Ответ 7

Пример приложения BookLibrary приложения WPF Application Framework (WAF) показывает, как Model-View-ViewModel (MVVM) можно использовать в сочетании с платформой Entity Framework.