Entity Framework 4 против NHibernate

Ответ 1

EF4 имеет готовый ответ в отношении разработки n-уровня в "объектах самоконтроля". Никто не выпустил сопоставимый код для NHib.

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

Ответ 2

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

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

Проблемы EF4:

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Изменить, 8/13/2012:

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

Существует очевидное trend увеличение популярности EF по сравнению с NHibernate, см. рисунок.

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

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

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

• Типы данных XML для карт основаны на расширениях или наиболее "ненавидящих" свойствах NotMapped... и это еще хуже.

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

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

Что мой 10cc.