Entity Framework 4 против NHibernate [закрыто]


114

В сети много говорилось о первой версии Entity Framework (также в stackoverflow), и ясно, что это был не лучший выбор, когда у нас уже есть лучшая альтернатива, такая как NHibernate. Но я не могу найти хорошего сравнения Entity Framework 4 и NHibernate. Мы можем сказать, что сегодня NHibernate является лидером среди всех .NET ORM, но можем ли мы ожидать, что Entity Framework 4 вытеснит NHibernate с этой позиции. Я думаю, что если Microsoft действительно внедрила очень хорошие функции в EF4, она может составить хорошую конкуренцию NHibernate, поскольку она имеет интеграцию с Visual Studio, с ней проще работать, и в большинстве магазинов всегда отдается предпочтение продуктам MS.


31
Я бы хотел обновить это сравнение. Много ли произошло с 2009 года?
Фил

Ответы:


66

У EF4 есть готовый ответ относительно n-уровневой разработки в «сущностях с самопроверкой». Никто не выпустил аналогичный код для NHib.

NHib имеет много функций, которые не были упомянуты как часть EF4. К ним относится интеграция кэша второго уровня. Он также обладает большей гибкостью в отображении наследования, лучшей интеграцией с хранимыми процедурами / функциями базы данных / настраиваемым SQL / триггерами, поддержкой свойств формул и так далее. ИМО это просто более зрелый как ORM.


13
+1 Ты прав. NH просто зрелый. EF наверстает упущенное к концу года. Версия 4.0 уже сделала впечатляющий выход. Подождите немного, и к середине 2011 года он станет пуленепробиваемым.

15
-1 Потому что «EF4 имеет готовый ответ относительно n-уровневой разработки, в« сущностях с самопроверкой ». Никто не выпустил сопоставимый код для NHib». В NHibernate есть ISession.Merge, который по многим причинам намного лучше, чем объекты Self-Tracking для разработки N-уровня.
Alex Burtsev

12
@Alex - Каким образом NHibernate - это готовое решение? Просто для уточнения; «Из коробки» означает, что он работает с обычной установкой Visual Studio. Это неоправданный -1.
Доктор Джонс

9
@DoctaJonez - Как я это читал, Алекс оспаривал идею о том, что у NH нет ничего, что можно было бы сравнить с объектами самопроверки, а не то, что это "из коробки".
Jerph

2
На самом деле я обнаружил, что EF4 имеет более гибкое сопоставление наследования. Например, вы можете использовать 2 таблицы (TPT) как базовый класс + класс уровня 1 и добавить дискриминатор в таблицу уровня 1, что позволяет разделить на классы уровня 2. В NH дискриминатор может быть определен только в базовом классе.
Дэнни Варод

37

Обновление: я не использовал Entity Framework с версии 4.0, поэтому мой ответ может быть устаревшим. Я все еще использую NH или чистый ADO .NET в своих проектах. И я даже не хочу смотреть, что нового в EF начиная с 4.0, потому что NH отлично работает.

На самом деле их довольно легко сравнить, когда вы использовали оба. У EF4 есть некоторые серьезные ограничения, я могу назвать некоторые, с которыми я столкнулся сам:

Проблемы EF4:

  • Активная загрузка и формирование результата : система активной загрузки EF4 (Include ("Path")) генерирует неправильный SQL с циклическим соединением JOIN, который будет выполнять в тысячи (не буквально) раз медленнее для отношений "многие ко многим", чем написанный вручную SQL (это фактически непригодный для использования).
  • Materializer не может материализовать связанные сущности : если вы думаете, что можете преодолеть предыдущую проблему, предоставив собственный SQL-запрос, вы ошибаетесь. EF4 не может материализовать (сопоставить) связанные сущности из запроса JOIN SQL, он может загружать данные только из одной таблицы (так, если у вас есть Order.Product, SELECT * FROM order LEFT JOIN Product инициализирует только объект Order, Product останется нулевым, думал, что все необходимые данные извлекаются в запросе для его инициализации). Это можно преодолеть с помощью надстройки сообщества EFExtensions, но код, который вам придется написать для этого, действительно уродлив (я пробовал).
  • Самостоятельно отслеживающие объекты: Многие говорят, что сущности с самотслеживанием - это круто для N-уровневой разработки, включая главный ответ в этой ветке. Думал, что даже не попробовал, могу сказать, что нет. Любой ввод можно подделать, вы не можете просто взять изменения, которые отправляет вам пользователь, и применить их к базе данных, почему бы не дать пользователю прямые данные базовый доступ тогда? В любом случае вам придется загрузить данные, которые пользователь собирается изменить из БД, проверьте, что он существует | не существует, проверяет разрешения и т.д. и т. Д. Вы не можете доверять пользователю в состоянии объекта, который он отправляет на сервер, вы все равно будете необходимо загрузить этот объект из БД и определить его состояние и другие вещи, поэтому эта информация бесполезна, как и объекты самотслеживания, если вы не используете частную доверенную n-уровневую систему для внутреннего использования, и в этом случае, возможно, вы могли бы дать просто Доступ к БД.

  • Ведение журнала, события, интеграция бизнес-логики: EF4 похож на черный ящик, он что-то делает, а вы понятия не имеете, что он делает. Есть только одно событие OnSavingChanges, в котором вы можете поместить некоторую бизнес-логику, которую нужно запустить, прежде чем что-то случится с БД, и если вам нужно применить некоторые изменения к бизнес-объектам до того, как что-то произойдет, вам придется копаться в ObjectStateManager, и это действительно уродливо , код может стать огромным. Если вы, например, используете шаблон репозитория и что нужно уведомлять об изменениях, внесенных в БД с помощью чистого объекта, вам будет сложно сделать это с EF.

  • Расширяемость: весь код EF является частным и внутренним, если вам что-то не нравится (и вам не понравится МНОГО, если вы серьезно относитесь к использованию EF), вы никак не сможете это легко изменить, на самом деле я уверен Легче написать собственный ORM с нуля (я сделал), а затем заставить EF работать так, как вам нужно. В качестве примера взгляните на исходный код EFExtensions, он основан на методах расширений и различных «хитростях», чтобы сделать EF более удобным для использования, а код довольно уродлив (и это не вина авторов, когда все в EF является частным, это единственное способ продлить его).

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

А как насчет NHibernate? Это совершенно другой уровень, это как сравнение PHP с C #, EF4 как в Stone-age, как будто EF на 10 лет отстает от NHibernate в развитии, и на самом деле это так, Hibernate был запущен в 2001 году. Если у вас есть свободное время чтобы узнать и включить Nhibernate, сделайте это.


1
EF был выпущен под лицензией Apache 2, что должно помочь с расширяемостью.
CMircea 01

@MirceaChirea Вот, отличные новости, я этого не ожидал, просматриваю исходный код EF прямо сейчас, довольно интересное чтение.
Alex Burtsev

2
-1 за несколько утверждений, которым предшествует: «Я не использовал это, но все равно говорю».
Kyeotic

@Tyrsius Мой ответ был написан почти 3 года назад, я давно не использую EF, некоторые вещи можно улучшить, вы можете отредактировать мой ответ, чтобы обновить его до текущего статуса EF.
Alex Burtsev

2
Вы признаете, что никогда не использовали объекты с самопроверкой, но все же отклоняете их. Как насчет того, чтобы говорить только о том, что вы знаете, и опускать невежественные догадки, тем более что весь этот абзац в значительной степени неверен.
Том Холладей

25

Вот в чем дело. На мой взгляд, NHibernate и Entity Framework действительно предназначены для двух разных аудиторий. NHibernate был бы моим выбором при построении системы со сложными сопоставлениями, формулами и ограничениями (в основном все корпоративные). Если бы я хотел приступить к работе с простым доступом к данным, я бы использовал Entity Framework или LINQ-to-SQL. NHibernate не имеет такой четкой функции «перетаскивания», как EF. У обоих есть свои сильные и слабые стороны. Честно говоря, сравнение их с яблоками ни к чему не приведет.


13
Вы пробовали ActiveWriter? Entity Framework абсолютно нацелена на корпоративное пространство. Я не согласен с большей частью того, что вы сказали.
Майкл Мэддокс,

1
Не соглашайтесь со всем, что вы хотите, но тот факт, что NHibernate существует дольше, - это то, что компании НЕ упускают.
zowens

21
-1 Это не очень хорошее сравнение NHibernate и Entity Framework. Сравнивать их, объединяя EF вместе с LINQ to SQL только b / c, у которого есть перетаскивание, в лучшем случае неискренне. Что касается сложности, что именно NHibernate может делать, а EF 4 - нет?
Кевин Бэбкок,

14
Кэширование второго уровня, их запросы ВЫСОКО оптимизированы, NH заставляет вас использовать шаблон UnitOfWork, плюс сопоставления не помещаются в один файл. Мое мнение (по опыту) заключается в том, что NHibernate более производительный. Не согласен со мной в этом, но я сказал, что это мое мнение. Моя точка зрения в моем ответе ВСЕ ЕЩЕ актуальна, у них ОБЕИХ есть сильные и слабые стороны. Никто не может этого отрицать.
zowens

2
@ MakerOfThings7 это жалко ... весь этот вопрос субъективен. Просыпайтесь ...
zowens

23

Если вы думаете, что когда-нибудь захотите запустить свой код на Mono, NHibernate, вероятно, будет лучшим выбором, независимо от того, что написано в контрольных списках функций ...

Изменить, 13.08.2012:

Entity Framework имеет открытый исходный код и теперь включен в Mono с 2.11.3. Этот ответ уже устарел, и на него не следует полагаться.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx


Действительно, на сайте mono-project.com/Compatibility написано «EntityFrameworks - Недоступно», и похоже, что никто не заинтересован в его реализации. Так что, по крайней мере, на несколько лет это NHibernate или ничего.
user276648

12

Я считаю, что EF4.0 прошел долгий путь со времен 1.0 и догоняет Nhibernate по функциональности, но это еще не все.

Однако это Microsoft, готовая к использованию, и она делает 100% того, для чего это нужно 95% приложений. Однако NHibernate уже много лет делает то же самое. Версия 5.0 или 6.0 может догнать или даже превзойти NHibernate.

Вот мой совет - если у вас есть время изучить оба, то сделайте это. Есть несколько причин выбрать одну из них. Если вы пишете код для корпорации, вполне реально ожидать, что у вас появятся способные сотрудники, которые будут знакомы с EF, поскольку это есть во всех книгах и том, что дети изучают в колледже. Если EF будет соответствовать вашим требованиям (подумайте об этом долго и усердно, прежде чем просто сказать «да»), тогда это прекрасное решение на данный момент, и через несколько лет оно может (хорошо, скорее всего) превзойти NHibernate.

NHibernate - очень зрелый продукт, проработавший на EF несколько лет и, скорее всего, сделает все, что вы когда-либо захотите, а затем и некоторые. Некоторое время это был лучший ORM, и многие люди его используют.


10

Я думаю, что тот факт, что EF 4 будет иметь возможность использовать POCO и отложенную ленивую загрузку, будет очень большим. Я определенно видел, как с новым релизом он набирает обороты.


7
Не забывайте о поддержке LINQ. NHibernate по-прежнему не умеет.
Арнис Лапса,

1
@Arnis, вы можете предоставить какие-либо ссылки, подтверждающие это мнение?
Майкл Мэддокс,

2
@Michael это становится очевидным, когда вы просматриваете сообщения в блоге Аянде на эту тему. LINQ to NH в настоящее время основан на API критериев. API критериев не поддерживает некоторые из более сложных функций запросов, которые может выполнять HQL. В следующем выпуске LINQ to NH будет использоваться HQL вместо API критериев.
zowens

5

Существует очевидная тенденция увеличения популярности EF по сравнению с NHibernate, см. Изображение.

NHibernate против Entity Framework


В чем суть вашего ответа? yourlogicalfallacyis.com/bandwagon
Рэзван Флавиус Панда

Согласно тенденции, люди со временем все чаще начинают использовать EntityFramework в Google. И у них могут быть для этого веские причины. Может, стало лучше.
Tomas Kubes

Это может быть так, также может быть, что это то, что предлагается по умолчанию для использования MS. Также неплохой набор инструментов для EF.
Рэзван Флавиус Панда

4

Мои 2 цента: мы используем ef на нашем настольном клиенте для некоторого кеширования и т. Д. - никаких высоких нагрузок. NHib на стороне сервера - использование сеансов без сохранения состояния, генерации идентификаторов hilo и пакетов. Is довольно быстро вставляет 3k + сообщений в дБ в секунду. Кроме того, он очень гибкий и поддерживает множество dbs, что очень важно для нашего продукта.


3

Сопоставление непосредственно с хранимыми процедурами с комбинацией Linq для логического уровня кажется самым простым подходом. Нет xml. Создавайте sql только для интересных запросов, которые реже используются или не подходят для хранимых процедур.

Объекты загружаются и сохраняются через стандартные SP. Этот подход позволяет использовать два входа в систему sql. Один для доступа к классу через SP (разрешения только на выполнение) и один для логического модуля linq, который позволяет прямой доступ к таблице.


1

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

ATM, моя точка зрения на EF такова: «Он предназначен для очень маленьких, довольно крошечных битовых систем с не более чем 3 таблицами с менее чем одной взаимосвязью (0 лучше)».

И почему я так думаю? 1. Попробуйте обновить отключенный график и посмотрите, как ваша модель царапается;

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

  2. Попробуйте делать более громоздкие запросы и смотреть, как вся система съедает стек: D ... переполнения случаются очень часто.

  3. Типы данных Map XML основаны на расширениях или наиболее «ненавистных» свойствах NotMapped ... и это даже хуже.

  4. Попробуйте смешать SQL-запрос с Linq для большего количества запросов, и вы сломаете стену, lol.

  5. И последнее и самое важное: EF не поддерживает формулу свойств («потрясающие ресурсы, которые у NH есть для устаревших баз данных») и не поддерживает сопоставления сложных типов для одной и той же таблицы и связанных таблиц.

Это мой 10cc.

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