Які критерії оцінювання ORM для.NET? [зачинено]

Я дивлюсь на оцінку ORM.

Я використовував SubSonic , Linq-SQL та Entity Framework . У мене є команда розробників, починаючи від юніорів до старших.

Які критерії оцінювання ORM для.NET?

Це завантажене питання.
Є дуже багато хороших ОРМ, які підходять до теми з різними філософіями.
Жоден не є ідеальним наскрізь, і всі, як правило, стають складними, як тільки ви відхилитесь від їх золотого шляху (а іноді навіть тоді, коли ви його дотримуєтесь).

Що ви повинні запитати у себе, вибираючи ORM:

1. Що для цього потрібно зробити?
   Якщо у вас вже є набір вимог до вашої заявки, вам слід вибрати ORM, який краще відповідає цим, а не гіпотетичному "кращому".

2. Ваші дані є спільними чи просто локальними?
   Багато волохатості в ORM обумовлено тим, як вони обробляють паралельність і зміни даних у базі даних, коли кілька користувачів містять версії одних і тих же даних.
   Якщо ваш сховище даних призначений для однокористувача, то більшість ОРМ виконають добру роботу. Однак задайте собі кілька складних питань у багатокористувацькому сценарії: як обробляється блокування? Що відбувається, коли я видаляю об'єкт? Як це впливає на інші суміжні об’єкти? Чи ORM працює поруч із металом бекенда або це кешування багатьох даних (покращення продуктивності за рахунок збільшення ризику несвіжості).

3. Чи ORM добре адаптований до вашого типу додатків? З конкретним ORM може бути важко працювати (велика ефективність роботи, важко кодувати), якщо він використовується в сервісі або сидить у веб-програмі. Навпаки, це може бути чудово для настільних програм.

4. Чи потрібно відмовлятися від конкретних удосконалень для бази даних?
   ORM, як правило, використовують найменший набір знаменників SQL, щоб забезпечити роботу з великою кількістю різних резервних даних.
   Усі ORM підуть на компроміс щодо доступних функцій (якщо вони спеціально не націлені на один бекенд), але деякі дозволять вам реалізувати додаткові способи поведінки для використання конкретних удосконалень, доступних у вибраному сервері.
   Типовим розширенням, характерним для db, є, наприклад, повнотекстові можливості пошуку; переконайтеся, що ваш ORM надає вам спосіб отримати доступ до цих функцій, якщо вони вам потрібні.

5. Як ORM управляє змінами в моделі даних?
   Деякі можуть автоматично оновлювати БД в певному вимірі, інші нічого не роблять, і вам доведеться робити брудну роботу самостійно; інші надають основу для обробки змін, яка дозволяє контролювати оновлення бази даних.

6. Чи маєте намір з'єднати вашу програму з об'єктами ORM чи ви віддаєте перевагу обробці POCO та користувачеві адаптер для постійності?
   Перший зазвичай простий в обробці, але створює залежності від ваших специфічних для ORM об'єктів даних скрізь, останні є більш гнучкими, ціною трохи більше коду.

7. Чи буде вам колись потрібно віддалено переносити свої об’єкти?
   Не всі ORM рівні, якщо мова йде про отримання об'єктів з віддаленого сервера, уважно подивіться, що можна чи неможливо зробити. Одні ефективні, інші - ні.

8. Чи є хтось, до якого можна звернутися за допомогою?
   Чи є хороша комерційна підтримка? Наскільки великою та активною є спільнота навколо проекту?
   Які проблеми виникають у користувачів із продуктом?
   Чи отримують вони швидкі рішення?

Кілька ОРМ, які я подивився:

• XPO
  Від розробника Express: невеликий і простий, орієнтований на код. Вони використовують це для своєї програми eXpressApp .
• NHibernate
  Безкоштовний, але крива навчання досить крута. Багато смаколиків, але важко знайти те, що дійсно актуально іноді у всій фрагментарній документації.
• LLBLGen Pro
  дуже зрілий проект, не найпростіший, але багато думок було вкладено в нього.
• Entity Framework
  GEtting там. Останні випуски досить хороші, а MS слухає, хоча він ще трохи молодий порівняно з іншими більш зрілими ОРМ.
• DataObject.Net
  Виглядає перспективно, але також є трохи новим, щоб ризикувати важливим проектом IMHO. Хоча досить активно.

Звісно багато інших.

Ви можете ознайомитись із суперечливим сайтом ORM Battle, який перераховує деякі орієнтири продуктивності, хоча ви повинні знати, що швидкість сировини - це не обов'язково найважливіший фактор для вашого проекту і що виробниками веб-сайту є DataObject.Net.

Я використовую NHibernate і вважаю це досить непоганим.

У моєму випадку пов'язано з базою даних MS Sql, але ви можете підключитися до інших баз даних.

Щоб встати та запустити не потрібно багато часу - просто нанесіть на об'єкт модель, - я використовую XML-файл, але ви можете це робити вільно в коді. Є велике співтовариство, і особисто я вважаю, що робота Айенди дуже корисна - я використовую NHProf, який є інструментом профілювання sql.

Я здебільшого використовую функції поза межами поля - пряме відображення об'єктів, але я також використовую мову запиту в сплячому режимі, яку досить легко отримати.

На жаль, у моїх останніх трьох робочих місцях у нас було три ОРМ в домашніх умовах. У кожному випадку вони в основному смоктали з різних причин.

Нещодавно я оцінював Entity Framework 4 та його підтримку POCO (приємний посібник тут ), і я дуже вражений тим, як чудово він залишається поза моїм обличчям і змушує мене відчувати, що я програмую знову, а не випасуючи дані.

Порівняння ORM та орієнтири на ORMBattle.NET

Мені дуже подобається Linq до Sql. Це просто і має гідного дизайнера. Однак я сподіваюся закінчити життя це на користь структури Entity. Я хотів би мати можливість використовувати можливість модифікувати генератори, щоб я міг мати індивідуальні об'єкти.

Найбільша вигода, яку вони мають над іншими (на мою думку), - це те, що вони вийшли з коробки з VS. Це також є негативним тим, що ви знаходитесь на милість MS (див. Linq to Sql).

[ВИСНОВОК: Я працюю в DevExpress]

Ви можете побачити скріншоти типових програм , створених з допомогою DevExpress середовищ розробки додатків тут . Ця сторінка також містить дуже короткий огляд нашої продукції. Для більш детальної інформації про те , чому я пропоную вам ознайомитись із відповідними сторінками продуктів на нашому веб-сайті.

Що стосується DevExpress XAF та XPO, то тут є хороше пояснення того, чому вибрати наші програми програм. Крім того, ми надаємо підтримку та документацію, що також важливо і варто згадати. Не соромтеся звертатися до нас у разі виникнення будь-яких питань.

Ми використовуємо NHibernate + Fluent NHibernate, з Linq-to-Sql для невеликих проектів. Причиною цього є:

1) (Не головна причина) NHibernate, здається, має більш високий фактор "поваги" серед розробників (це правда?),

2) Порівняно з linq-to-SQL, nHibernate дозволяє картографувати ORM між об'єктами Db і об'єктами, які не відображають 1-до-1,

3) Ми широко не порівнювали nHibernate з Entity Framework 4.0, але ось хороше порівняння: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate має дещо круту криву навчання, і його XML-карти можуть бути досить багатослівними, але почніть з документації на сайт Fluent Nhibernate і працюйте назад.

Не існує "найкращої" системи ORM, тому що всі вони мають різні комбінації сильних і слабких сторін, і, як правило, якщо розробники вирішили зосередитись на тому, щоб зробити одну область кращою, є інші області, які страждають у порівнянні (код спочатку проти модель спочатку проти бази даних спочатку).

З іншого боку, є ряд дуже хороших, деякі з яких будуть краще відповідати вашим особистим обставинам та філософії, ніж інші.

Редагувати: Для чого варто, я в даний час використовую Linq для SQL - здебільшого тому, що це там, хоча частково тому, що він робить багато прав для мінімальних зусиль і, ймовірно, знову перейде до Entity Framework знову "тому що його є" (хоча аналогічно також є багато що про EF4 це правильно, а також деякі речі, які неправильно). Занепокоєння, особливо щодо останнього, повинно викликати ефективність, але для більшості моїх випадків це не величезна проблема, а можливість запуску динамічних даних та OData з моделей (L2S та EF) має для мене значні переваги з точки зору " дешево "виграє.

Я б порадив вам поглянути на DevExpress XPO . Це разом з DevExpress XAF полегшить життя будь-якого розробника, коли його крива навчання буде перекреслена.

Нам пощастило з Entity Framework. Однак наша ситуація дещо незвична - ми збираємо дані для звітної команди, тому вони насправді розробляють базу даних. Ми отримуємо БД, а потім просто використовуємо EF для генерації з неї класів доступу до даних. Для нас чудово працює, але ми просто робимо масові навантаження даних, тому я не можу поручити, наскільки це добре в більш транзакційних умовах.

NHibernate (+ FluentNHibernate) був би для мене типовим варіантом. Він дуже гнучкий, розтяжний і надійний. У нього є величезна кількість користувачів, і це дуже активно підтримується. Мінусом є крута крива навчання.

LightSpeed ​​MindScape простий і зручний, але все ще досить гнучкий і здатний. Він має дизайнерську поверхню на зразок L2S / EF та реалізацію UnitOfWork.

Ну, немає "найкращого" вибору, але я б сказав, що звичайний старий Linq для SQL відповідає вашим потребам. Це не "справжній" ORM як такий, але він дуже легкий і дає вам можливість писати код, не усвідомлюючи цього, якщо це має сенс. Я маю на увазі те, що ви можете продовжувати писати код як звичайно, не маючи правдиво знати про Linq, окрім наявності dbmlфайлів. Ви все ще можете писати абстракції над ним, використовуючи шаблони сховища або шлюзу, і L2S виконує головну роль ORM, яка полягає в тому, щоб обійти об'єктно-реляційне невідповідність.

Entity Framework трохи важкий, і хоч я лише дебютував з ним, він трохи більше "в обличчі", ніж базовий Linq для Sql, але EF набагато більше справжнього ORM, ніж Linq. Я хотів би переглянути всі критерії, які ви шукаєте в ORM. Це лише тому, що ви хочете уникнути необхідності писати необроблений SQL або, що ще гірше, мати сотні збережених процедур? Вам потрібні додаткові функції, які сирий Linq для Sql не може надати? Вам потрібно відповісти на ці запитання, але виходячи з вашої короткої вимоги ("легка і проста у використанні"), я думаю, що Linq трохи простіше, ніж щось на зразок Subsonic, і вбудований в Visual Studio.

ECO :) Це набагато більше, ніж ORM, в тому числі включаючи державні машини та виконувану підтримку OCL (а саме EAL). Існує безкоштовна версія з обмеженням на 12 доменних класів, які, на мою думку, повинні бути досить акуратними для невеликих проектів.