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

.net architecture entity-framework

Вопрос

Я использую Entity Framework O / R mapper от Microsoft и использую классы сущностей (сгенерированные классы, которые отображаются на объекты БД) в качестве бизнес-объектов. Это нормально? Пожалуйста, укажите ваши минусы или плюсы. Что делать в случае связи WCF между бизнес-уровнем и презентацией, как отправить эти объекты в качестве элементов данных?

Принятый ответ

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

Также взгляните на эту ссылку на MSDN, которая описывает некоторые распространенные сценарии использования с EF в отношении Business Logic.


Популярные ответы

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

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

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

Пара разъяснений, прежде чем я начал:

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

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

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

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

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

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

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

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

В этом суть дискуссии.

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

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

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

  1. Как и многие разработчики, мы посеяли это зерно в нашем мозгу во время обучения - «консолидация кода» имеет первостепенное значение или, возможно, более известна как «СУХОЙ» - «Не повторяйте себя», и поэтому вы можете посмотреть на дублирование кода, например как свойства, в отрицательном контексте.
  2. ORM, такие как EF 4.1, имеют технические ограничения (и хакерские обходные пути), такие как сопоставление нескольких POCO / объектов в одну таблицу базы данных, что вынуждает вас делать это независимо от ваших убеждений.
  3. Это быстрый и простой способ запустить и запустить приложение
  4. Это «чувствует», как правильно делать

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

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

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

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

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

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

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

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

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

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

Вы можете ответить на вопрос о том, является ли постоянное невежество с ORM нелепым, учитывая, что целью является управление данными. :-) Извините, я не удержался!



Related

Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему
Лицензировано согласно: CC-BY-SA with attribution
Не связан с Stack Overflow
Является ли этот КБ законным? Да, узнайте, почему