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

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

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

в ef4 проблемы:

• нетерпеливая загрузка и формирование результата: EF4 eager loading system (Include ("Path")) генерирует неправильный SQL, с циклическим соединением , которое будет выполнять тысячи (не буквально) раз медленнее для отношений "многие ко многим", а затем рукописный SQL (он фактически непригоден).
• материализатор не может материализовать связанные объекты: Если вы можете думать, что вы можете преодолеть предыдущую проблему, предоставив вам собственный SQL-запрос, вы неправильный. EF4 не может материализовать (сопоставить) связанные объекты из запроса JOIN SQL, он может загружать данные только из одной таблицы (так что если у вас есть порядок.Product, SELECT * FROM order LEFT JOIN Product будет инициализировать только объект Order, продукт останется нулевым, думал, что все необходимые данные извлекаются в запросе, чтобы инициализировать его ). Это можно преодолеть с помощью дополнения сообщества EFExtensions, но код, который вам придется написать для этого, действительно уродлив (я пробовал).

• Саморегулирующимся Сущности: многие говорят, что самонастраивающиеся объекты хороши для N-уровневой разработки, включая верхний ответ в этом потоке. Я думал, что даже не дал им попробовать, я могу сказать, что это не так.Каждый ввод может быть подделан, вы не можете просто взять изменения, которые пользователь отправляет вам, и применить их к базе данных, почему бы не дать пользователю прямой доступ к базе данных? В любом случае вам придется загрузить данные, которые пользователь собирается изменить из БД, проверьте, что он существует|не существует, проверяет разрешения и т. д. и т. д. Вы не можете доверяйте пользователю о состоянии объекта, который он отправляет на сервер, вам в любом случае придется загрузить этот объект из БД и определить его состояние и другие вещи, поэтому эта информация бесполезна, как и самонастраивающиеся объекты, если вы не делаете частную доверенную n-уровневую систему для внутреннего использования, и в этом случае, возможно, вы могли бы дать просто доступ к БД. (Это мои мысли о St Entities и N-tire, я не очень опытен в N-уровне, поэтому он может измениться, если я что-то неправильно понял здесь комментарий это)

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

• расширяемость: весь код EF является частным и внутренним, если вам что-то не нравится (и вам не понравится много, если вы серьезно относитесь к использованию EF), вы не сможете легко изменить это, на самом деле я уверен, что вам легче написать собственный ORM с нуля (я сделал), а затем заставить EF работать так, как вам нужно. В качестве примера взгляните на Источник EFExtensions, он основан на методах расширений и различных "хак", чтобы сделать EF немного более удобным, и код довольно уродлив (и это не вина авторов, когда все в EF является частным, это единственный способ расширить его).

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

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

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

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

Edit, 8/13/2012:

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

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

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

однако это Microsoft, из коробки, и сделать 100% того, что 95% приложений нужно это сделать. Тем не менее, NHibernate делает то же самое в течение многих лет. Приходите версии 5.0 или 6.0 может догнать, или даже превзойти NHibernate.

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

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

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

есть очевидная тенденция о повышении популярности EF над NHibernate, см. рисунок.

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

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

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

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

ATM моя точка зрения об EF: "это сделано для действительно небольших довольно крошечных битных систем С не более чем 3 таблицами с менее чем 1 отношением (0 лучше)".

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

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

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

3. Map XML datatypes основан на расширениях или самых "ненавистных" свойствах NotMapped... и это еще хуже.

4. попробуйте смешать SQL-запрос в Linq для более finner запросы и вы сломаете стену лол.

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

Это мой 10cc.