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

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

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

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

пара уточнений, прежде чем я начал:

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

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

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

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

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

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

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

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

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

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

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

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

1. как и у многих разработчиков, у нас есть это семя, посаженное в наш мозг во время обучения "консолидация кода" имеет первостепенное значение или, возможно, более известный как сухой – не повторяйте себя, и поэтому вы можете смотреть на дублирование кода, такие как свойства, в негативном контексте.
2. платформ, таких как EF 4.1, имеют технические ограничения (и хакерские обходные пути), такие как отображение нескольких POCOs/объектов в одну и ту же таблицу базы данных, тем самым заставляя вас независимо от ваших убеждений.
3. это быстрый и простой способ получить приложение и работает
4. это "чувствует", как правильная вещь, чтобы сделать

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

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

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

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

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

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

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

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

надеюсь, что это помогает.

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

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

по состоянию на .Net 3.5 с пакетом обновления 1, они также должны можно использовать как типы paramater и return в методах службы WCF без какого-либо дополнительного кода.

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

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

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

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

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

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

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

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

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

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