Чи є вагомі причини не використовувати ORM? [зачинено]

Під час мого навчання я використовував NHibernate для деяких менших проектів, які я здебільшого кодував і розробляв самостійно. Тепер, перш ніж розпочати якийсь більший проект, дискусія виникла, як створити доступ до даних та використовувати чи рівень ORM чи ні. Оскільки я все ще перебуваю у своєму навчанні і все ще вважаю себе новачком у програмуванні підприємств, я не дуже намагався підштовхувати свою думку, що полягає в тому, що використання об’єктного реляційного картографа в базі даних може значно полегшити розвиток. Інші кодери в команді розробників набагато досвідченіші за мене, тому я думаю, що я просто зроблю те, що вони кажуть. :-)

Однак я не повністю розумію дві основні причини не використання NHibernate чи подібного проекту:

1. Можна просто створити власні об’єкти доступу до даних за допомогою SQL-запитів та скопіювати ці запити з Microsoft SQL Server Management Studio.
2. Налагодження ORM може бути важким.

Тож, звичайно, я міг би просто створити свій рівень доступу до даних з великою кількістю SELECTs тощо, але тут я пропускаю перевагу автоматичних приєднань, класів пролегливих завантажень проксі та менших зусиль з обслуговування, якщо таблиця отримує новий стовпчик або стовпець перейменований. (Оновлення численний SELECT, INSERTі UPDATEзапити проти поновлення відображення конфігурації і , можливо , рефакторінга бізнес - класи і DTOs.)

Також, використовуючи NHibernate, ви можете зіткнутися з непередбаченими проблемами, якщо не дуже добре знаєте рамки. Це може бути, наприклад, довіривши Table.hbm.xml, де ви встановили довжину рядка для автоматичної перевірки. Однак я також можу уявити подібні помилки в "простому" рівні доступу до даних на основі запитів SqlConnection.

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

(Я, мабуть, слід додати, що я думаю, що це як перший "великий" .NET / C # додаток, який вимагатиме командної роботи. Належні практики, які сприймаються як нормальні для переповнення стека, такі як тестування блоків або безперервна інтеграція, не є -існуючі тут дотепер.)

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

Чому ORM ускладнить налагодження? Ви отримаєте той самий результат, незалежно від того, чи є він із збереженого протоколу або з ORM.

Я думаю, що єдиний реальний збиток, який я можу подумати за допомогою ORM, - це те, що модель безпеки трохи менш гнучка.

EDIT: Я просто перечитав ваше запитання, і, схоже, вони копіюють і вставляють запити в вбудований sql. Це робить модель безпеки такою ж, як ORM, тому не було б абсолютно ніякої переваги перед цим підходом над ORM. Якщо вони використовують непараметризовані запити, це насправді буде ризиком для безпеки.

Коротка відповідь - так, є справді вагомі причини. Власне, є випадки, коли ви просто не можете використовувати ORM.

Справа в тому, що я працюю у великій фінансовій установі підприємства, і ми повинні дотримуватися багатьох рекомендацій щодо безпеки. Для дотримання правил та норм, які застосовуються до нас, єдиний спосіб пройти аудит - це збереження доступу до даних у межах збережених процедур. Зараз деякі можуть сказати, що це просто дурно, але, чесно кажучи, це не так. Використання інструмента ORM означає, що інструмент / розробник може вставляти, вибирати, оновлювати чи видаляти все, що він хоче. Збережені процедури забезпечують набагато більшу безпеку, особливо в умовах, коли працює з клієнтськими даними. Я думаю, що це найбільша причина вважати. Безпека.

Мила пляма ОРМ

ORM корисні для автоматизації 95% + запитів, де вони застосовні. Їх особлива сила полягає в тому, що у вас є додаток із сильною архітектурою об'єктної моделі та базами даних, яка чудово грає з цією об'єктною моделлю. Якщо ви робите нову збірку та маєте сильні навички моделювання у вашій команді, ви, ймовірно, отримаєте хороші результати за допомогою ORM.

Можливо, у вас є кілька запитів, які краще виконувати вручну. У цьому випадку не бійтеся написати кілька збережених процедур, щоб впоратися з цим. Навіть якщо ви плануєте перенести додаток на кілька платформ СУБД, код бази даних буде в меншості. Зважаючи на те, що вам потрібно буде протестувати свою програму на будь-якій платформі, на якій ви маєте намір її підтримувати, трохи додаткових зусиль для перенесення деяких збережених процедур не призведе до значного значення для вашого TCO. Для першого наближення, 98% портативний настільки ж хороший, як і 100% портативний, і набагато краще, ніж згорнуті або погано ефективні рішення для роботи в межах ОРМ.

Я бачив, як колишній підхід добре працював над дуже великим проектом J2EE (100 років на персонал).

Де ORM може не найкраще підходити

В інших випадках можуть бути підходи, які краще відповідають заявці, ніж ORM. « Шаблони архітектури прикладних програм підприємства» має розділ про шаблони доступу до даних, що робить досить непоганою роботою каталогізацію різних підходів до цього. Я бачив декілька прикладів ситуацій, коли ORM може не застосовуватися:

• У програмі зі значною базою застарілих кодів збережених процедур ви можете використовувати функціонально орієнтований (не плутати з функціональними мовами) шар доступу до даних, щоб обернути діючі паростки. Це повторно використовує існуючий (і тому тестований та налагоджений) рівень доступу до даних та дизайн бази даних, що часто представляє досить значні зусилля щодо розробки та тестування, і економить на необхідності переміщення даних до нової моделі баз даних. Часто це досить хороший спосіб обернути шари Java навколо застарілих баз кодів PL / SQL або повторно націлити на додатки VB, Powerbuilder або Delphi багаті клієнти з веб-інтерфейсами.

• Варіація полягає в тому, коли ви успадковуєте модель даних, яка не обов'язково добре підходить для ІЛИ відображення. Якщо (наприклад) ви пишете інтерфейс, який заповнює або витягує дані з іноземного інтерфейсу, можливо, вам буде краще працювати безпосередньо з базою даних.

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

• Високопродуктивні програми, де ви хочете реально налаштувати доступ до вашої бази даних. У цьому випадку може бути кращим працювати на нижчому рівні.

• Ситуації, в яких ви використовуєте діючий механізм доступу до даних, наприклад ADO.Net, який є "досить хорошим" і грає добре з платформою, приносить більше користі, ніж приносить ORM.

• Іноді дані - це лише дані - можливо так (наприклад), що ваша програма працює з "транзакціями", а не з "об'єктами", і це розумне уявлення про домен. Прикладом цього може бути фінансовий пакет, де у вас є транзакції з налаштованими полями аналізу. Хоча сама програма може бути побудована на платформі OO, вона не прив’язана до єдиної моделі ділового домену та може не знати більше, ніж коди GL, акаунти, типи документів та півдесятка полів аналізу. У цьому випадку додаток не знає моделі бізнес-домену як такої, а об'єктна модель (за межами самої структури книги) не стосується програми.

По-перше, використання ORM не полегшить тестування вашого коду, а також не обов'язково надасть переваги в сценарії безперервної інтеграції.

На мій досвід, хоча використання ORM може збільшити швидкість розвитку, найбільші проблеми, які вам потрібно вирішити, це:

1. Тестування вашого коду
2. Підтримання коду

Рішення для них:

1. Зробіть свій код перевіреним (використовуючи принципи SOLID )
2. Напишіть автоматизовані тести на якомога більше коду
3. Запускайте автоматизовані тести якомога частіше

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

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

Є дві причини, чому я не використовую ORM:

1. Це категорично заборонено політикою компанії (в такому випадку я б пішов працювати кудись інше)
2. Проект надзвичайно обширний для даних, і більше сенсу використовувати специфічні для постачальника рішення (наприклад, BulkInsert).

Звичайні відсічі щодо ОРМ (зокрема NHibernate):

1. Швидкість

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

2. Складність

   Що стосується складності, використання ORM означає менше коду, що, як правило, означає меншу складність. Багато людей, які використовують рукописний (або генерований код) доступ до даних, виявляють, що вони пишуть власну структуру через "низькорівневі" бібліотеки доступу до даних (наприклад, допоміжні методи для ADO.Net). Вони прирівнюються до більшої складності, і, що ще гірше, вони рідко добре документально підтверджені або добре перевірені.
   Якщо ви спеціально дивитесь на NHibernate, то такі інструменти, як Fluent NHibernate та Linq To NHibernate також пом’якшують криву навчання.

Що мене викликає у всьому дискусії щодо ORM, це те, що ті самі люди, які заявляють, що використання ORM буде занадто важким / повільним / будь-які ті самі люди, які більш ніж задоволені, використовуючи Linq To Sql або Набрані набори даних. У той час, як Linq To Sql - це великий крок у правильному напрямку, все ще залишаються світлові роки позаду, де є деякі ORM з відкритим кодом. Однак рамки як для типових наборів даних, так і для Linq To Sql все ще надзвичайно складні, і використовувати їх для того, щоб зайти занадто далеко (Таблиця = Клас) + (базовий CRUD), дурно складно.

Моя порада полягає в тому, що якщо в кінці дня ви не можете отримати ORM, тоді переконайтеся, що ваш доступ до даних відокремлений від решти коду, і ви дотримуєтесь рекомендації Gang Of Four щодо кодування до інтерфейс. Крім того, отримайте рамку для ін'єкцій залежності, щоб виконати проводку.

(Як це за оренда?)

Існує широкий спектр поширених проблем, для яких такі засоби ORM, як Hibernate, передаються богом, і деякі, де це перешкода. Я не знаю достатньо про ваш проект, щоб знати, що це таке.

Одним із сильних моментів Hibernate є те, що ви можете сказати речі лише 3 рази: кожне властивість згадується в класі, файл .hbm.xml та база даних. За допомогою SQL запитів ваші властивості знаходяться в класі, базі даних, операторах вибору, операторах вставки, операторах оновлення, операціях видалення та всьому коді, який підтримує ваші SQL запити! Це може швидко заплутатися. З іншого боку, ви знаєте, як це працює. Ви можете налагодити це. Тут все добре у вашому шарі наполегливості, а не закопаний у надрах стороннього інструменту.

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

EDIT: Ви можете заглянути в iBatis.NET, якщо вони не збираються звертатися до NHibernate і вони хочуть контролювати свої запити SQL.

EDIT 2: Ось ось великий червоний прапор: "Хороші практики, які вважаються досить нормальними для переповнення стека, такі як тестування блоків або безперервна інтеграція, поки що тут не існує". Отже, ці "досвідчені" розробники, що вони мають у розробці? Їх безпека роботи? Здається, що ви можете бути серед людей, які не особливо зацікавлені в цій галузі, тому не дозволяйте їм вбивати ваш інтерес. Вам потрібно бути балансом. Помирись.

Я працював над одним проектом, де не використовуючи ORM було дуже успішно. Це був проект, який

1. Мав бути горизонтальним масштабом з самого початку
2. Треба було швидко розвиватися
3. Мав відносно просту модель домену

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

Так, у 90% проектів, над якими я працював над ОРМ, була неоціненною допомогою. Але є деякі дуже специфічні обставини, коли я бачу, як не використовувати ORM як найкращий.

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

Я виявив, що при проектуванні систем, що мають високі вимоги до продуктивності, мені часто постають завдання знайти способи зробити систему ефективнішою. Багато разів я закінчую рішенням, яке має важкий профіль продуктивності запису (тобто ми записуємо дані набагато більше, ніж ми читаємо дані). У цих випадках я хочу скористатися послугами, які пропонує платформа бази даних для досягнення наших цілей ефективності (це OLTP, а не OLAP). Тож якщо я використовую SQL Server і знаю, що маю багато даних для запису, то чому б я не використав об'ємну вставку ... ну, як ви, можливо, вже виявили, більшість ORMS (я не знаю, чи навіть один) не має можливості скористатися певними перевагами платформи, наприклад, масовими вставками.

Ви повинні знати, що ви можете поєднувати методи ORM та non-ORM. Щойно я виявив, що є кілька крайових випадків, коли ORM не можуть підтримати ваші вимоги, і вам доведеться обійти їх для цих випадків.

Коли вам потрібно оновити 50000000 записів. Встановіть прапор чи що завгодно.

Спробуйте зробити це за допомогою ORM, не викликаючи збережену процедуру або нативні команди SQL.

Оновлення 1: Спробуйте також отримати один запис із лише кількома його полями. (Коли у вас дуже "широкий" стіл). Або скалярний результат. ORM також смокчуть це.

ОНОВЛЕННЯ 2 : Схоже, що бета-версія EF 5.0 обіцяє пакетні оновлення, але це дуже гаряча новина (2012, січень)

Для нетривіального корпоративного додатка на базі даних насправді немає обґрунтування не використовувати ORM.

Особливості:

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

Щоб поставити певну перспективу в аргумент, врахуйте переваги використання ADO.NET проти написання коду для розбору табличного потоку даних.

Я бачив незнання того, як використовувати ORM, виправдовувати зневагу розробника до ORM. Наприклад: прагнення до завантаження (те, що я помітив, ви не згадали). Уявіть, що ви хочете отримати клієнта та всі його замовлення, а також усі ці деталі замовлення. Якщо ви покладаєтесь лише на ледачий навантаження, ви відійдете від досвіду ORM з думкою: "ОРМ повільні". Якщо ви навчитесь використовувати нетерпляче завантаження, ви за 2 хвилини зробите 5 рядків коду, на що вашим колегам знадобиться півдня на реалізацію: один запит до бази даних та прив’язка результатів до ієрархії об’єктів. Іншим прикладом може бути біль ручного написання SQL запитів для впровадження пейджингу.

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

Не дозволяйте досвіду старших членів команди перетягнути вас у зворотному напрямку еволюції інформатики. Я професійно розвиваюся вже 23 роки, і одна з констант - це зневага до старої школи. ORM призначені для SQL, як мова С для збирання, і Ви можете зробити ставку, що еквіваленти C ++ і C # наступають. Один рядок нового шкільного коду дорівнює 20 рядків старої школи.

Я думаю, що, можливо, коли ви працюєте у великих системах, ви можете використовувати інструмент генератора коду, як CodeSmith замість ORM ... Нещодавно я виявив це: Framework Cooperative, що генерує збережені процедури SQL Server, а також генерує ваші суб’єкти господарювання, картографи, шлюзи, lazyload та все те, що в C # ... перевірити ... це було написано командою тут, в Аргентині ...

Я думаю, що це посередині між кодуванням всього рівня доступу до даних та використанням ORM ...

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

Тепер більшість моїх веб-розробок використовує Django, і я вважаю, що включений ORM є дуже зручним, і оскільки модель даних виражається спочатку в їхніх термінах, а вже пізніше в SQL, вона працює ідеально для моїх потреб. Я впевнений, що перерости це не буде надто складно, і потрібно доповнити рукописний SQL; але для CRUD доступу більш ніж достатньо.

Я не знаю про NHibernate; але я думаю, що це також "досить добре" для більшості того, що вам потрібно. Але якщо інші кодери не вірять цьому; це буде головним підозрюваним у всіх помилках, пов’язаних з даними, що робить перевірку більш втомливою.

Ви можете спробувати впровадити його поступово на своєму робочому місці, зосередившись спочатку на невеликих «очевидних» програмах, як-от простий доступ до даних. Через деякий час він може бути використаний на прототипах, і він не може бути замінений ...

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

Я думаю, що є багато вагомих причин не використовувати ORM. По-перше, я - розробник .NET і мені подобається дотримуватися того, що чудова рамка .NET вже мені надала. Це робить усе, що мені, можливо, потрібно. Роблячи це, ви дотримуєтесь більш стандартного підходу, і, таким чином, є набагато більше шансів, що будь-який інший розробник, який працює над тим самим проектом вниз, зможе підібрати те, що там, і побігти з ним. Можливості доступу до даних, які вже надає Microsoft, є досить багатими, і немає причин відкидати їх.

Я 10 років був професійним розробником, очолював декілька дуже успішних проектів на мільйон + доларів, і жодного разу не писав заявки, необхідної для переходу на будь-яку базу даних. Чому б вам хотілося, щоб клієнт це робив? Ретельно сплануйте, підберіть потрібну базу даних для того, що вам потрібно, і дотримуйтесь її. Особисто SQL Server міг робити все, що мені потрібно було робити. Це легко, і це чудово працює. Існує навіть безкоштовна версія, яка підтримує до 10 ГБ даних. О, і це чудово працює з .NET.

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

Чесно кажучи, я думаю, що для ORM є одне реальне використання: якщо ви створюєте додаток на зразок SAP, він дійсно потребує можливості роботи на кількох базах даних. В іншому випадку, як постачальник рішень, я кажу своїм клієнтам, що ця програма створена для роботи на цій базі даних, і саме так воно і є. Знову ж таки, через 10 років і незліченну кількість заявок, це ніколи не було проблемою.

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

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

Я раніше не використовував сплячку, але одне, що я помітив, за допомогою декількох "позаштатних" рішень щодо ОРМ, це відсутність гнучкості. Я впевнений, що це залежить від того, з ким ти йдеш і що з цим потрібно робити.

Є два аспекти ОРМ, які викликають занепокоєння. По-перше, це код, написаний кимось іншим, іноді закритим джерелом, іноді відкритим кодом, але величезним за обсягом. По-друге, вони копіюють дані.

Перша проблема викликає два питання. Ви покладаєтесь на код сторонніх осіб. Ми все це робимо, але вибір до цього не слід сприймати легко. А що, якщо він не робить те, що потрібно? Коли ви це відкриєте? Ви живете всередині вікна, яке ваш ORM малює для вас.

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

Я пропоную це читання для переліку мінусів ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Для себе я знайшов ORM дуже корисними для більшості написаних нами програм!

/ Асгер

Досвід, який я мав із Hibernate, полягає в тому, що його семантика є тонкою, і коли є проблеми, трохи важко зрозуміти, що відбувається під кришкою. Я чув від друга, що часто хтось починає з Критеріїв, потім потрібна трохи більша гнучкість і потрібен HQL, а пізніше помічає, що врешті-решт, потрібний сирий SQL (наприклад, у Hibernate немає об'єднання AFAIK).

Крім того, з ORM, люди легко схильні до використання існуючих відображень / моделей, що призводить до того, що існує об'єкт з великою кількістю атрибутів, які не ініціалізовані. Тож після запиту Hibernate всередині транзакції робить додаткове отримання даних, що призводить до потенційного уповільнення. Також сумно, що об'єкт сплячої моделі іноді просочується в шар архітектури перегляду, і тоді ми бачимо LazyInitializationExceptions.

Щоб користуватися ORM, треба реально це зрозуміти. На жаль, легко складається враження, що це легко, а ні.

Як не відповідь сама по собі, я хочу перефразувати цитату, яку я чув недавно. "Хороший ОРМ - це як єті. Усі говорять про одного, але його ніхто не бачить".

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

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

Я думаю, що використання ORM все ще є хорошою ідеєю. Особливо враховуючи ситуацію, яку ви надаєте. Згідно з вашим дописом, ви досвідченіший, коли йдеться про стратегії доступу до db, і я б вирішив використовувати ORM.

Немає аргументу для №1, оскільки копіювання та вставлення запитів та жорстке кодування тексту не дають гнучкості, а для №2 більшість орм зафіксують оригінальний виняток, дозволять відслідковувати генеровані запити тощо.

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

Написання власних рамок може бути трудомістким, і часто щось пропускається.

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

Кожна ОРМ, навіть "хороша", оснащена певною кількістю припущень, пов’язаних з базовою механікою, яку програмне забезпечення використовує для передачі даних між вашим додатком і вашим сховищем даних.

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

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

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

Інакше, до біса з ОРМ. Зараз я вважаю їх в основному придумами.