Во-первых, на момент написания 11 000 вопросов я немного удивлен отсутствием ответов и при всем уважении к качеству ответов, учитывая довольно простой вопрос.
Итак, теперь, когда я немного высказался, я хотел бы ответить на этот вопрос (-ы), потому что я думаю, что он применим еще больше сегодня с недавним выпуском 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 предназначен для поддержки управления данными. Его главная ответственность - данные, и поэтому создаваемые вами объекты ориентированы на данные. Так что, если вы пытаетесь спроектировать свои объекты по поведению, у вас есть небольшая головоломка. В двух словах, эта загадка называется несоответствием импеданса. Изобразите это; в вашем приложении есть два обязательных варианта использования:
- Экран для редактирования пользователя
- Элемент управления для отображения только для чтения подмножества пользовательской информации
Если вы используете EF (любой вариант) или любой ORM в этом отношении, вы можете стремиться использовать один и тот же объект «Пользователь» для обработки возможности сохранения пользователя, а также извлечения пользователя для извлечения подмножества чтения и чтения. только поля. Вы, вероятно, делаете это по одной из нескольких причин:
- Как и многие разработчики, нам посеяно это зерно во время обучения, поскольку «консолидация кода» имеет первостепенное значение или, возможно, более известна как СУХОЙ - не повторяйте себя, и поэтому вы можете посмотреть на дублирование кода, например свойства, в отрицательном контексте.
- ORM, такие как EF 4.1, имеют текТехнические ограничения (и хакерские обходные пути), такие как сопоставление нескольких POCO / объектов в одну таблицу базы данных, что вынуждает вас делать это независимо от ваших убеждений.
- Это быстрый и простой способ запустить и запустить приложение
- Чувствуется, что это правильно
В этом есть свои преимущества и недостатки, и вы можете посмотреть на это как положительно, так и отрицательно, в зависимости от вашего мнения.
Полагаю, если вы верите в нормализацию кода по поведению, то вы значительно преуспели. Вы смогли ограничить объем кода, потенциально сэкономив время, написав один объект для обработки ваших данных и вариантов использования бизнеса для этой сущности.
И я полагаю, если вы верите в нормализацию поведения по коду, вы с треском провалились. Экономя на коде, вы жертвовали проектированием объектов, выполняя их обязанности, что потенциально затрудняет управление и впоследствии увеличивает затраты на обслуживание.
Независимо от вашего мнения, мы, вероятно, все можем согласиться с тем, что этот бизнес-объект взял на себя множество обязанностей, и поведение (а не данные!) Объекта в лучшем случае является вторичным. Его основная ответственность заключается в управлении данными, а второстепенными обязанностями является обработка простых и сложных бизнес-правил, связанных с редактированием пользователя и отображением информации только для чтения. В объектно-ориентированном проектировании (OOD), если дизайн объекта характеризуется своей индивидуальностью и поведением, этот объект может быть одним запутанным человеком, поскольку он не придерживается самого определения OOD.
С технической точки зрения необходимо учитывать, что каждый раз, когда вы запрашиваете пользовательский объект, вы наследуете значительные накладные расходы. Это может включать такие вещи, как все свойства и бизнес-правила при отображении только подмножества информации только для чтения.
Так, как все это связано с тем, должен ли я использовать EF для представления своих бизнес-объектов?
Ну ... Хотя это технически возможно, существуют разные философии (некоторые хорошие, некоторые плохие) относительно того, следует ли использовать EF или какой-либо ORM для представления своих бизнес-объектов. Я дал краткий обзор, нацеленный на суть этих философий выше, но они задокументированы гораздо более подробно такими людьми, как Роки Лхотка и Мартин Фаулер.
Направление, которое вы выберете, скорее всего, будет зависеть от приложения и с философской точки зрения, может зависеть от того, насколько вы идеалист или прагматик. Тем не менее, я не намекаю на то, что человек, являющийся идеалистом или прагматиком, коррелирует с использованием EF для бизнес-объектов или без него - это просто повлияет на ваше мнение об этом.
На момент написания этой статьи Microsoft указала, что EF созданы для работы с бизнес-логикой, и, как ни крути, они движутся в этом направлении больше. EF постоянно развивается, и некоторые технические ограничения снимаются так, что EF может в конечном итоге использоваться для удовлетворения лучшего из обоих миров. Другими словами, в конечном итоге вы сможете получить свой торт и съесть его тоже.
Надеюсь, это поможет.
Не отвечайте на вопрос о том, является ли постоянное невежество с ORM нелепым, учитывая, что целью является управление данными. :-) Извините, я не удержался!