Какие аргументы ПРОТИВ использования EntityFramework? [закрыто]


31

Приложение, которое я сейчас создаю, использует хранимые процедуры и созданные вручную модели классов для представления объектов базы данных. Некоторые люди предлагают использовать Entity Framework, и я подумываю перейти на это, так как я не так далеко от проекта. Моя проблема в том, что я чувствую, что люди, выступающие за EF, говорят мне только о хорошем, а не о плохом :)

Мои основные проблемы:

  • Мы хотим, чтобы проверка на стороне клиента осуществлялась с использованием DataAnnotations, и, похоже, мне все равно нужно создавать модели на стороне клиента, поэтому я не уверен, что EF сэкономит столько времени на кодирование.
  • Мы хотели бы, чтобы классы были как можно меньше при работе по сети, и я прочитал, что использование EF часто включает дополнительные данные, которые не нужны
  • У нас есть сложный слой базы данных, который пересекает несколько баз данных, и я не уверен, что EF справится с этим. У нас есть одна общая база данных с такими вещами, как Users, StatusCodes, Types и т. Д., А также несколько экземпляров наших основных баз данных для разных экземпляров приложения. Запросы SELECT могут и будут запрашивать все экземпляры баз данных, однако пользователи могут изменять только те объекты, которые находятся в базе данных, над которой они работают в настоящее время. Они могут переключать базы данных без перезагрузки приложения.
  • Объектные режимы очень сложны, и часто требуется довольно много объединений

Аргументы в пользу EF:

  • Параллелизм. Мне не нужно кодировать в чеках, чтобы увидеть, обновлялась ли запись перед каждым сохранением
  • Генерация кода. EF может генерировать частичные модели классов и POCO для меня, однако я не уверен, что это действительно сэкономило бы мне столько времени, так как я думаю, что нам все еще нужно будет создать клиентские модели для проверки и некоторые пользовательские методы анализа.
  • Скорость разработки, поскольку нам не нужно создавать хранимые процедуры CRUD для каждого объекта базы данных.

Наша текущая архитектура состоит из службы WPF, которая обрабатывает вызовы базы данных с помощью параметризованных хранимых процедур, объектов POCO, которые отправляются в / из службы WCF и клиента WPF, и самого клиента рабочего стола WPF, который преобразует POCO в класс Models с целью проверки и DataBinding.

Итак, мой вопрос, подходит ли EF для этого? Есть ли подводные камни в EF, о которых я не знаю?


Проверьте это тоже .. сравнение производительности и поддержки LINQ: ormeter.net
M.Sameer

Ответы:


7

Недавно я оценивал Entity Framework, и лучшее место, где я нашел проблемы и отсутствующие функции, было: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Пункты с наибольшим количеством голосов:

  1. Поддержка перечислений. Этот довольно большой, но в настоящее время есть некоторые обходные пути
  2. Улучшена генерация SQL. Скорость действительно важна, особенно для приложений уровня предприятия, но, похоже, с EF4 она значительно улучшилась
  3. Поддержка нескольких баз данных. Требование для любого большого применения.

В списке пользовательских тембров много других проблем.

Кстати, я очень взволнован предстоящим выпуском EF 4.1, который будет включать в себя подход Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-релиз-кандидат-available.aspx

Это на самом деле может подтолкнуть меня попробовать EF в производственном приложении.


Аргумент против: 1-го и 2-го и 3-го: это медленно! Есть кривая обучения (нужно знать, как сделать левое соединение - требуется 3 часа, чтобы найти способ, как это сделать, чтобы другой человек знал, что делается ...), переход на страницы в LINQ вместо SQL (например, feches 10 миллионов строк, затем берет 20 из них с произвольным смещением, и затем вы задаетесь вопросом, почему это так медленно) ... Репо безопасен без протектора, вы должны инициировать его для каждого запроса, и инициализация репо ОЧЕНЬ МЕДЛЕННО (например, 5 секунд), если у вас большая база данных (это означает 100-200 таблиц, а не ДЕЙСТВИТЕЛЬНО ДЕЙСТВИТЕЛЬНО больших).
Задор

2
@Quandary Похоже, что вы выполняете IQueryables (т.е. вызываете .ToList()или .ToArray) до того, как ваши выражения LINQ будут полностью определены. Вот почему он тянет все записи и делает это медленно.
Орад

6

Выполнение ветвления на ошибку / функцию с EF может быть чрезвычайно болезненным во время слияния. Представьте, что две ветви A и B вносят изменения в базу данных (что, вероятно, произойдет много на ранних этапах нового проекта).

Вы объединяете все «нормальные» файлы - файлы cs и т. Д. И тогда пора объединить Model.edmx. И вдруг вы не просто объединяете логические отображения между вашей объектной моделью и базой данных, но также и положения таблиц в диаграмме сущностей.

Объединение Model.edmx настолько болезненно, что мы приняли довольно неприятный способ, который работает:

  • Во время слияния просто выберите все слияния от одного из родителей. Что не имеет значения; в любом случае вы скоро поджарите файл:
  • Верните Model.edmx любому из родителей.
  • Переведите вашу базу данных в новое объединенное состояние.
  • Откройте Model.edmx и «Обновить модель из базы данных».
  • Переименуйте все свойства навигации, добавленные во время слияния.

1
Эта критика недействительна для EF Code First, но относится к Model First и Database First.
Алан Макдональд

Я создаю все отображения самостоятельно, используя Fluent, и беру полный контроль над отображением. Они помещены в отдельный файл .cs.
Стивен Райссерт

5

Есть несколько других преимуществ для EF, которые вам не хватает:

  • Вы можете иметь таблицы охвата Entity
  • Вы можете разбить таблицу на несколько типов сущностей
  • Вы можете генерировать сущности из базы данных (то есть базы данных в качестве основного подхода)
  • Вы можете сгенерировать базу данных из сущностей (т.е. код как основной подход)
  • LINQ-запросы преобразуются в SQL-запросы, улучшая их производительность.

Недостатки (особенно если вы используете проверку):

  • Вы должны создать атрибут [MetadataClass], который указывает на другой класс, обладающий свойствами, которые вы хотите проверить с соответствующими атрибутами проверки. Все свойства являются objectтипами, так что это просто для чтения метаданных. Еще много лишнего неактивного кода.
  • Использование EntityFramework - это другая концепция, чем то, как работает что-то вроде NHibernate (и родительской версии Java). EntityFramework лучше всего работает в подключенном режиме, когда объекты постоянно используют живое соединение. NHibernate и аналогичные инструменты ORM лучше всего работают в отдельном режиме, когда соединение используется только при загрузке / сохранении данных.

Это две самые большие жалобы, которые у меня есть. Есть ряд преимуществ, но вы вполне можете получить те же преимущества от NHibernate. Если EntityFramework находится на столе, попросите команду также проверить NHibernate и быстро выяснить плюсы и минусы вашего проекта.

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

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


Ваш так называемый код как мастер- подход официально называется сначала кодом
Роберт Коритник,

1
@ Берин, я хочу уточнить, что вы имеете в виду под «подключенным режимом». Я не думаю, что Entity Framework имеет постоянную связь с базой данных. Я считаю, что в этом отношении EF работает аналогично NHibernate. Это то, что вы имеете в виду или вы имеете в виду что-то еще? У вас есть ссылка на документацию, которая объясняет эту проблему?
RationalGeek

1
К прилагается, я имею в виду все ваши взаимодействия с объектами должно происходить в пределах от using(EFConnection conn = new EFConnection)конструкции. Если вы попытаетесь спрятать этот объект где-нибудь для безопасного хранения, чтобы вы могли выполнить быстрое обновление и снова сохранить его во втором using(...)утверждении, вам придется подумать еще раз. См. Msdn.microsoft.com/en-us/library/bb896271.aspx и msdn.microsoft.com/en-us/library/bb896248.aspx . Использование EF 3.5 (которое мне приходилось использовать в последней версии) не совсем чистое.
Берин Лорич

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

2
Это неправда. EF имеет четкое представление об отдельных лицах. Отсоединенный объект должен быть повторно присоединен к его контексту, прежде чем вы сможете выполнять с ним связанные с контекстом операции (например, обновлять его в базе данных). Также классы метаданных необходимы, только если EF генерирует ваши сущности для вас. POCO, IMO, - намного лучший способ использовать EF. Использование POCO значительно упрощает многие вещи, в частности тестирование.
Мэтт Грир,

2

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

В частности, EF1 (.net 3.5) очень отличается от EF4 (.net 4.0) - то же самое может произойти для следующей версии.

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

В то же время рассмотрите возможность использования nHibernate - он не эквивалентен, но он зрелый и широко используется.


1
  • Просто ... Доменная модель редко является копией реляционной модели в вашей базе данных. Поэтому сопоставление некоторых таблиц с классом и перебрасывание их по проводам - ​​просто лень. Таблицы могут локально отображаться в 1 объект, даже если база данных состоит из 3 разных таблиц. Проектируйте базу данных разумно.
  • Во-вторых, этот материал EF не может генерировать определенные запросы, и вам все равно придется их писать.
  • 3-я. Модель предметной области не отображается непосредственно на сервисы. Нужно будет только передавать самый минимальный набор данных по сети как DTO. Особенно, если она будет взаимодействовать с мобильными приложениями.
  • 5-я способность к тестированию ... Невозможно создать достаточно детальные тесты, которые обеспечат достаточную регрессию против изменений кода ... все это легко
    сломать ...

Я мог бы написать 10 страниц страницы. Но, если вы просто пишете какое-то одноразовое приложение для компании X ... кого это волнует. Но если вы разрабатываете программный продукт ... вам придется быть намного более анальным


этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
комнат

EF не генерирует доменные объекты. Это DAO. Вам нужно будет использовать данные объекта для создания объекта вашего домена. В любом случае вам не следует отправлять доменные объекты обратно из службы, поэтому создайте более тонкий DTO из своих доменных объектов, прежде чем вернуться. EF должны быть в состоянии генерировать большинство все , что вы можете выразить в LINQ. База данных не является частью модульного теста, это часть функционального теста. Тем не менее, в памяти есть макеты, доступные для EF. В противном случае абстрагируйте ваши EF-запросы в хранилище, а затем смейтесь над этим.
Синастетическая

Да, я согласен. Скорее, я имею в виду шаблоны, установленные Мартином Фаулером и Каригом Лэйрманом. В конце дня я не могу использовать CTE, PARTITION BY или CROSS APPLY. Кроме того, я не могу использовать IDataReader, который позволяет поддерживать низкую нагрузку на память. Кроме того, когда я запускаю SQL Trace и вижу, что EF посылает по проводам, я чувствую, что могу бросить ;-)
user104468

0

Проверьте это: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Основными моментами являются:

  • Отсутствие ленивой загрузки
  • Отсутствие упорства невежества
  • Формат файла, используемый для сохранения модели объекта, содержит как элементы визуализации, так и сама модель объекта вызывает проблемы слияния в командной среде.

Обратите внимание, что ссылка выше говорит о EF1.

Также эта ссылка: http://ormeter.net/ показывает, что EF не самый лучший по сравнению с другими ORM по производительности и поддержке LINQ.


Имейте в виду, что это было опубликовано, когда EF 1 был еще недавно выпущен (или, возможно, все еще находится в бета-версии). Сегодня ситуация с EF 4 намного лучше, и многие вопросы, поднятые в ходе этого голосования о недоверии, были решены.
RationalGeek

Последний пункт все еще имеет значение и очень важен.
М.Самир

1
Первая версия EF была 3.5. Там не было выпущено четыре основные версии EF.
Мэтт Грир

3
@ Матт, это правильно. Но текущая версия называется EF 4, чтобы соответствовать остальной версии .NET 4.
RationalGeek

1
Действительна она или нет, однако не должна влиять на сводку ссылки. Голоса покажут, если это действительно. :)
Адам Лир
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.