Какие аргументы ПРОТИВ использования 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, о которых я не знаю?

architecture orm entity-framework Рейчел
источник
Проверьте это тоже .. сравнение производительности и поддержки 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 в производственном приложении.

Mag20
источник
Аргумент против: 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 ... кого это волнует. Но если вы разрабатываете программный продукт ... вам придется быть намного более анальным

user104468
источник
этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
комнат
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.

M.Sameer
источник
Имейте в виду, что это было опубликовано, когда EF 1 был еще недавно выпущен (или, возможно, все еще находится в бета-версии). Сегодня ситуация с EF 4 намного лучше, и многие вопросы, поднятые в ходе этого голосования о недоверии, были решены.
RationalGeek
Последний пункт все еще имеет значение и очень важен.
М.Самир
1
Первая версия EF была 3.5. Там не было выпущено четыре основные версии EF.
Мэтт Грир
3
@ Матт, это правильно. Но текущая версия называется EF 4, чтобы соответствовать остальной версии .NET 4.
RationalGeek
1
Действительна она или нет, однако не должна влиять на сводку ссылки. Голоса покажут, если это действительно. :)
Адам Лир