Будете ли вы использовать версию 3.5 ADO.NET Entity Framework или подождать версии 4.0?

Question

Я был удивлен, обнаружив публичное письмо с предложением о недоверии к структуре организации (см. http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/)

Могут ли причины, указанные в письме, помешать вам использовать текущую версию структуры сущностей? Вы бы предпочли подождать v4.0? Или лучше использовать другой ORM?

Answer 1

Текущая версия EF определенно не идеальна и имеет много ошибок и недостатков. Возможно, я бы сейчас не использовал его, но путь обновления до EF v2 (или это EF4?) Выглядит довольно радужно!

• полное невежество - вы можете использовать свои классы POCO прямо
• отложенная загрузка настраивается как опция
• значительно улучшенный дизайнер с поддержкой множественного числа / сингулярности (даже на нескольких языках!)
• возможность проектировать "сначала домен" и создавать базу данных из вашей модели
• возможность иметь самоконтроль сущностей на нескольких уровнях, что позволяет отправлять данные клиенту, получать изменения и применять их к контексту вашей сущности

В целом, EF v2 выглядит очень многообещающе, и я очень хочу дать ему серьезную поддержку. Если он действительно выполняет все обещания прямо сейчас, это определенно победитель!

Посетите блог команды ADO.NET , чтобы узнать о недавних публикациях в блоге EF v2.

Марк

Answer 2

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

Это просто не работает.

Во-первых, если вы пытаетесь основать сущность на основе представления, дизайнер пытается заставить каждое свойство NOT NULL быть ключом сущности ... что почти никогда не соответствует тому, что я хотел. Чтобы обойти это, вы должны отредактировать XML как минимум в двух местах и ​​делать это каждый раз, когда добавляете объект, потому что он обновляет и повторно добавляет свойства EntityKey. Нужно ли указывать сопоставление для всех ключевых свойств в Entity Framework?

Во-вторых, когда вы создаете ассоциации, вы ДОЛЖНЫ использовать каждый ключ объекта - Как вы можете создать ассоциацию, не используя все ключи объекта в структуре объекта?

Эти две вещи держали меня в течение 3 дней, затем я вернулся к Linq для SQL и сделал это за пару часов. (Ну, по крайней мере, часть системы, с которой я боролся ...) Я не знаю, включены ли они в «Голосование о недоверии», но, на мой взгляд, она еще не готова.

Также из-за отсутствия ответов, которые я получил здесь на каждый вопрос EF, я должен предположить, что текущее использование настолько низкое, что получение помощи и поддержки будет затруднено ... что, возможно, является БОЛЬШОЙ причиной использовать что-то.

Будем надеяться, что следующая версия лучше ...

РЕДАКТИРОВАТЬ: Наш текущий план состоит в том, чтобы придерживаться Linq 2 SQL (я должен закончить проект к пятнице), а затем оценить все другие ORM, чтобы увидеть, что еще лучше. Другой разработчик ненавидит L2S за запись, но у меня никогда не было серьезных проблем с его использованием ...

Answer 3

Другой ОРМ.

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

Я фанат TDD, поэтому хочу легко тестируемое решение POCO ORM. Если это ваша сумка, то EF3.5 отсутствует. EF4.0 вводит его (http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx), но он все еще имеет как минимум 1 большой недостаток -> не поддерживает наследование.

NHibernate более полный, но EF может быть проще в использовании. Как всегда, лучший инструмент для работы ... но если это приложение, разработанное для корпоративного масштаба TDD, пойдите nHibernate.

Также -> есть профилировщик, который значительно упрощает разработку nHibernate -> http://www.nhprof.com/

Answer 4

EF имеет богатую поддержку времени разработки, но я должен согласиться с тем, что nHibernate - это путь, несмотря на кривую обучения. Если вам нужно что-то сделать быстро и не заботиться о TDD или сериализации (что является серьезным недостатком всех предложений MS ORM), переходите на EF.

Answer 5

Ну, мой опыт версии 1 был интересным. Я хотел использовать POCO, но он не поддерживал это. После прочтения я наткнулся на некоторый код из тела в Microsoft, который сделал это.

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

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

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

Буду ли я использовать EF 4.0 (2.0). Да, конечно, почему бы и нет? На самом деле на этапе 2 я буду использовать это. Похоже, что он поддерживает POCO, похоже, что моя модель параллелизма будет двигаться без проблем (в основном, с дельта-копированием). Пока все хорошо, и я надеюсь, что на этот раз «большие парни» из Microsoft увидели ошибки в своих действиях и предложили решение, которое работает.

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

Если вы не купитесь на Entity, то я бы настоятельно рекомендовал Enterprise Library. Это проверенная технология, которая работает каждый раз на основе надежного кода и парадигмы, ориентированной на базы данных. Я бы тоже пошел по этому пути, если вы думаете, что хранимые процедуры - это колени пчел, и вам нравится то, что они приносят на стол.

Если вы чувствуете себя действительно экзотично и чувствуете себя немного резвым, я бы выбрал подход NO-SQL, такой как CouchDB. Это, однако, требует некоторого привыкания. Это чертовски странно и кажется действительно очень неправильным. Но все развивается очень быстро, и решения кажутся надежными и быстрыми, чем ожидалось. Я не получил бы для этого типа решения, хотя, если вы большой в нормализации и думаете, что это может быть применено к подходу NO-SQL. Вся модель должна быть перевернута с ног на голову, а приложение необходимо будет смоделировать таким образом, чтобы это зависело от применяемой технологии.

Я считаю, что CouchDB немного грязный и очень-очень неправильный. Но у него так много веских причин использовать его, что, я думаю, он проникнет в психику каждого программиста и определенно станет массовым в следующие пару лет.

Мое самое большое недовольство в целом сущностью Entity, хотя даже в новой версии 4 то, что в N-уровневых средах действительно мало кто задумывался. Он по-прежнему чувствовал, что это двухуровневое решение с большим количеством кода, которое еще предстоит сделать конечному пользователю (разработчику), чтобы оно работало надежным и надежным способом N-уровня.