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 / тригерами, підтримка властивостей формули тощо. IMO в основному просто більш зрілий як ORM.

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

Насправді порівняти їх досить просто, коли ви використовували обидва. Є кілька серйозних обмежень щодо EF4, я можу назвати деякі, з якими зіткнувся сам:

Проблеми з EF4:

• Швидке завантаження та формування результату : система завантаження EF4 нетерплячих (Включити ("Шлях")) створює неправильну SQL, циклічно підключаючись до JOIN, яка виконуватиме тисячі (не буквально) часу повільніше для багатьох відносин, а потім рукописний SQL (це ефективно непридатний).
• Матеріалізатор не може матеріалізувати асоційовані об'єкти : Якщо ви думаєте, що можете подолати попередню проблему, надавши власний SQL-запит, ви помиляєтесь. EF4 не може здійснити (відображення) асоційованих об'єктів із запиту JOIN SQL, він може завантажувати дані лише з однієї таблиці (Отже, якщо у вас є Order.Product, SELECT * З замовлення Лівий приєднаний продукт ініціалізує лише об'єкт замовлення, продукт залишиться нульовим, подумав, що всі необхідні дані збираються у запиті, щоб запустити його). Це можна подолати за допомогою доповнення спільноти EFExtensions, але код, який вам доведеться написати для цього, справді некрасивий (я намагався).

• Суб’єкти самовідстеження: Багато хто каже, що особи, які відстежують самості, відзначають розвиток N-рівня, включаючи головну відповідь у цій темі. Думав, що я навіть не намагаюся їх спробувати, можу сказати, що це не так. Кожен вхід можна підробити, ви не можете просто прийняти зміни, які надсилає вам користувач, і застосувати їх до бази даних, чому б не дати користувачеві прямі дані базовий доступ тоді? Будь-який спосіб вам доведеться завантажувати, щоб користувач даних змінився з БД, переконайтеся, що вони існують | не існує перевірок дозволів тощо. Ви не можете довіряти користувачеві про стан особи, яку він надсилає на сервер, ви все одно доведеться завантажувати цю сутність з БД і визначати, що це стан та інші речі, тому ця інформація є марною, як і суб'єкти самостеження, якщо ви не використовуєте приватну довірену систему 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 до 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 ідентифікаторів та пакетів. Досить швидко вставляє 3k + повідомлень у db за секунду. Крім того, він дуже гнучкий і підтримує багато dbs, що є вирішальним для нашого продукту.

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

Об'єкти завантажуються та зберігаються через стандартні ІП. Цей підхід дозволяє використовувати два sql логіни. Один для доступу до класу через SP-адреси (лише для виконання дозволів) та один для логічного модуля linq, який дозволяє прямий доступ до таблиці.

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

Банкомат моєї точки зору щодо EF виглядає так: "Він створений для дійсно невеликих досить крихітних бітових систем, що мають не більше 3 таблиць з менш ніж 1 співвідношенням (0 краще)".

І чому я так думаю? 1. Спробуйте оновити відключений графік і побачити нулю своєї моделі;

1. Спробуйте створити TPH з глибоко успадкованими деревами, і ви виявите, що ви потрапили в єдину ієрархію або система зламається.

2. Спробуйте зробити більш громіздкі запити і спостерігайте, як вся система з'їдає стек: D ... переливи трапляються дуже часто.

3. Характеристика даних XML на основі заснованих на розширеннях або самих "ненависних" властивостях NotMapped ... і це ще гірше.

4. Спробуйте змішати SQL-запит у Linq для більш тонких запитів, і ви зламаєте стінку lol.

5. І останнє і найважливіше - EF не підтримує формулу властивостей ("дивовижні ресурси, які NH має для застарілих баз даних"), і не підтримує відображення складних типів для тієї ж таблиці та пов'язаних з ними таблиць.

Це мій 10 куб.