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

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

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

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

Обновление: я не использовал 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, сделайте это.

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

Если вы думаете, что когда-нибудь захотите запустить свой код на 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

Я считаю, что 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 на нашем настольном клиенте для некоторого кеширования и т. Д. - никаких высоких нагрузок. NHib на стороне сервера - использование сеансов без сохранения состояния, генерации идентификаторов hilo и пакетов. Is довольно быстро вставляет 3k + сообщений в дБ в секунду. Кроме того, он очень гибкий и поддерживает множество dbs, что очень важно для нашего продукта.

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

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

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

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

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

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

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

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

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

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

Это мой 10cc.