Истории успеха Платформы объекта?
4 ответа
Хотя я склонен соглашаться с Тимом в отношении «религиозного» элемента выбора фреймворка, мне все же кажется немного странным, что так много людей готовы прокомментировать EF, когда они так явно скрывают Не удосужился узнать, как это работает. Оказывается, EF будет паршивой версией NHibernate, точно так же, как молотки делают плохие отвертки. Важно понимать EF как таковой.
Прежде чем я коснусь некоторых вопросов, поднятых здесь в комментариях, я добавлю, что мы только что отправили версию 2 рабочего веб-приложения с 0 строками SQL и 100 % всего доступа к БД нашим клиентам через EF или API членства в ASP.NET. Я говорю здесь, имея реальный опыт использования EF, что, к сожалению, явно не относится к авторам большинства комментариев к EF I ' я видел до сих пор.
В общем, я считаю ошибкой расширять ваши типы сущностей. Автор сообщения в блоге, на которое ссылается Тим (1) не знал, что это возможно, и (2) думает, что это путь для реализации DDD, говорит мне все, что мне нужно знать о его реальном опыте работы с EF: Он
Поддержка POCO стала очень большой проблемой для пользователей некоторых ORM, потому что у них не было функциональной реализации LINQ в течение многих лет. Поскольку вы, по сути, застряли с объектами любого типа, выходящими из черного ящика, контроль над родительским типом стал очень важным делом. Настолько велико, что написание ваших «POCO» с каждым участником , объявленным публичным виртуальным , стало неважным. На какой планете это «равнина»? Это прокси-база, а не POCO. Так называемые «POCO» вообще не являются POCO. Просто они предпочитают идти на компромисс в отношении инкапсуляции и производительности, а не родительского типа. Вероятно, это законный компромисс в рамках ограничений их набора инструментов, но не о чем дерзать.
Но EF работает иначе; Материализовать произвольный тип с помощью проекций LINQ так же легко, как и тип, который вы фактически сопоставили. Если вы создаете что-то для отправки объектов по сети, а не для внутреннего использования, и должны иметь клиентов, которые не могут зависеть от EF, тогда вы используете службы RIA или пишете службу данных ADO.NET. Вся тяжелая работа будет сделана за вас. EF является основой семейства инструментов, решающих проблему проецирования данных в БД на различные типы клиентов, а не на одного, автономный инструмент, который пытается обрабатывать каждое отдельное преобразование данных, которое может потребоваться приложению внутри, в одной толстой структуре. Пусть EF обрабатывает проекцию из СУБД в объектное пространство. Затем вы можете использовать, например, LINQ to Entities для проецирования в типы, игнорирующие персистентность, или службы RIA для проецирования в удобный для Silverlight формат проводов. Просить один инструмент для обработки каждой проекции, которая может когда-либо понадобиться любому приложению, - это умолять застрять в гетто с этим инструментом.
EF основан на понятии «объекты ценности». Это типы со свойствами, но без поведения. Оказывается, объекты-значения очень хорошо работают для определенных конкретных задач, таких как отправка данных по сети или пребывание в «нейтральной зоне» между РСУБД и объектно-ориентированным программированием. Это Важно понимать разделение проблем здесь : Суть типов сущностей состоит в том, чтобы получить данные RDB в пространстве объектов. Затем вы можете написать бизнес-типы, которые реализуют ваше приложение, и спроецировать типы сущностей на бизнес-типы. Тогда у вас будет свобода реализовать свои типы бизнеса без компромиссов в отношении настойчивости. При необходимости вы можете изменить схему RDB. Вам нужно только изменить отображение объектов и проекции BO, а не сами BO.
При необходимости вы можете изменить схему RDB. Вам нужно только изменить отображение объектов и проекции BO, а не сами BO. При необходимости вы можете изменить схему RDB. Вам нужно только изменить отображение объектов и проекции BO, а не сами BO.Проблема с этим типом вопросов заключается в том, что в выборе фреймворков людьми присутствует элемент "религии", а ORM внушают немало страсти.
Так что рискуйте. определенного пламени ... Я лично не большой поклонник Entity Framework, я вижу, где было бы неплохо взять устаревшую систему и модель ER и сопоставить ее, но я думаю, что в долгосрочной перспективе (и мое использование case) больше построен на дизайне модели предметной области и для того, чтобы мои сущности были сопоставлены с этим. Здесь есть хорошая запись в блоге , с которой я склонен согласиться.
Я думаю, что мне нравится подход, который используют такие продукты, как NHibernate и Eco . И в настоящее время я экспериментирую с настоящей OODBMS (вместо ORM) с DB4Objects и пока очень впечатлен.
Краткий ответ: подождите, пока EF 4.0
Длинный ответ:
Сейчас я завершаю проект EF 1.0 среднего размера (также ASP.NET MVC). У меня тоже есть опыт работы с NHibernate. Помимо обычных сопоставлений CRUD, мы провели немало моделирования наследования. В целом мои чувства по этому поводу смешанные.
Несколько наблюдений:
Лучшее, что я могу сказать о EF 1.0, - это то, что он имеет отличную интеграцию с LINQ. Он лучше, чем Linq to NHibernate (в его текущем выпуске).
EF может хорошо обрабатывать интересные сопоставления наследования, но вы обнаруживаете МНОГО ошибок сопоставления, пытаясь исправить это. Документация здесь не очень полезна, и сообщество пока не пользуется большой поддержкой. Вы просто должны это понять.
Конструктор содержит ошибки и не поддерживает все, что может делать EF. Часто приходится редактировать файлы сопоставления XML вручную. Дизайнер создает ошибки при правильном сопоставлении xml. Фактически, у нас было так много проблем с дизайнером, что мы сначала перейдем к XML, а не позволим дизайнеру обновлять сопоставления. Я бы сказал, что это проблема, с которой я сталкиваюсь с продуктами Microsoft в целом: они создают продукты, ориентированные на инструменты, а не на библиотеки. В данном случае они поспешили с инструментами, потому что XML также плох.
XML, э-э, многословен. EF 1.0 требует большого количества картографической информации. В отличие от XML NHibernate, который занимается только отображением и не требует концептуального определения или файла определения хранилища, или, что еще лучше, такого инструмента, как Fluent NHibernate, который позволяет вам указывать свои сопоставления в коде.
Лично я предпочитаю писать классы, которые сами могут быть сохранены (POCO), а не иметь дело с отдельной моделью сущностей данных. Несмотря на точку зрения Крейга о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом в отношении намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не преодолевая множество препятствий.
Возможно, самое большое раздражение EF - это отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем охотно использовать его снова.
лично я предпочитаю писать классы, которые сами могут быть сохранены (POCO), а не иметь дело с отдельной моделью сущностей данных. Несмотря на точку зрения Крейга о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом в отношении намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не прыгнув через множество препятствий.Возможно, самым большим раздражением EF является отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем охотно использовать его снова.
лично я предпочитаю писать классы, которые сами могут быть сохранены (POCO), а не иметь дело с отдельной моделью сущностей данных. Несмотря на точку зрения Крейга о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом относительно намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не прыгнув через множество препятствий.Возможно, самым большим раздражением EF является отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем снова с радостью воспользуюсь им.
предпочитают писать классы, которые сами могут быть сохранены (POCO), а не работать с отдельной моделью сущностей данных. Несмотря на точку зрения Крейга о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом относительно намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не преодолевая множество препятствий.Возможно, самое большое раздражение EF - это отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем охотно использовать его снова.
предпочитают писать классы, которые сами могут быть сохранены (POCO), а не работать с отдельной моделью сущностей данных. Несмотря на точку зрения Крейга о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом в отношении намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не преодолевая множество препятствий.Возможно, самое большое раздражение EF - это отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем снова с радостью воспользуюсь им.
Несмотря на то, что мы говорим о публичном виртуальном, я предпочитаю прокси-подход NHibernate. Я не могу согласиться с Крейгом в отношении намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не прыгнув через множество препятствий.Возможно, самым большим раздражением EF является отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем охотно использовать его снова.
Несмотря на то, что мы говорим об общедоступном виртуальном сервере, я предпочитаю прокси-сервер NHibernate. Я не могу согласиться с Крейгом в отношении намерений EF. Я не думаю, что они предполагают, что вы создаете слой сопоставления между EF и вашими бизнес-объектами. Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не прыгнув через множество препятствий.Возможно, самым большим раздражением EF является отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем охотно использовать его снова.
Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не прыгнув через множество препятствий.Возможно, самым большим раздражением EF является отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем снова с радостью воспользуюсь им.
Как частичные классы, кажется, что вы добавляете поведение к своим сущностям, чтобы создать полный объектно-ориентированный класс. Имея это в виду, вы не можете выполнить модульное тестирование EF 1.0, не преодолевая множество препятствий.Возможно, самое большое раздражение EF - это отсутствие прозрачной отложенной загрузки. Это действительно отстой.
Я подожду, пока выйдет EF 4.0, прежде чем снова с радостью воспользуюсь им.
Мы используем NHibernate в InterWorks уже 4 года. Он отлично сработал для нас, и мы создали еще один слой поверх него, чтобы упростить использование (аналогично Castle ActiveRecord, о которых мы не знали в то время).
Недостатками NHibernate являются кривая обучения, отсутствие сильного инструмента с графическим интерфейсом (мы используем наши собственные шаблоны MyGeneration для создания объектов) и поддержка сообщества OK. Мы приложили много усилий, чтобы заставить его работать на нас, и потратили немало времени на обучение новых членов команды работе с NHibernate и фреймворком, который мы построили вокруг него.
Поскольку мы создаем в основном специализированное программное обеспечение, это сложно для чтобы оправдать накладные расходы на перестройку нашего фреймворка, но, скорее всего, в следующие два года мы перейдем на Entity Framework по паре очень простых причин. (1) Лучшая документация и более широкое сообщество поддержки (это произойдет быстро) и (2) Легче найти людей с опытом работы в EF, что устранит некоторые затраты на обучение.
Сегодня это не так, но они появятся довольно быстро в следующем выпуске EF в VS.NET 2010. Он действительно повзрослел, и благодаря встроенной поддержке VS.NET он успешно развивается. Мы провели с ним несколько базовых тестов, но я не утверждаю, что обладаю обширным опытом работы с EF.
MS нужно немного поработать с программой, но теперь, когда у них есть EF, он будет здесь надолго. придет и станет стандартом. Если у вас нет опыта в ORM, я бы начал изучать EF, это будет лучше для вашей карьеры в долгосрочной перспективе.
но теперь, когда у них есть EF, они будут здесь надолго и станут стандартом. Если у вас нет опыта в ORM, я бы начал изучать EF, это будет лучше для вашей карьеры в долгосрочной перспективе. но теперь, когда у них есть EF, они будут здесь надолго и станут стандартом. Если у вас нет опыта в ORM, я бы начал изучать EF, это будет лучше для вашей карьеры в долгосрочной перспективе.