Навіщо використовувати ORM? [зачинено]

113

Якби ви мотивували "плюси", чому б ви використовували ORM для управління / клієнта, які б причини були?

Спробуйте зберегти одну причину за кожну відповідь, щоб ми бачили, що за найкращі причини голосується

database  orm 
— Саймон Манро
джерело
3
ви повинні зробити це вікі, якщо хочете опитування
— frankodwyer
+1 за те, щоб зробити це вікі, якщо ви хочете опитування
— клетус
16
А що з конфа?
— Брайан Меттьюз
4
І жодної ложки. Ні, справді, є суперечка: виступ. Набагато простіше оптимізувати запити БД, коли вам не потрібно проходити ORM. (Я не скаржусь - нещодавно перейшов на ORM, я здебільшого задоволений цим; загалом, ORM - це шлях, але тримати запити ближче до металу, якщо вам потрібна продуктивність)
— Пісквор вийшов з будівлі
2
@ UğurGümüşhan, IMHO головна перевага використання ORM полягає в тому, щоб зробити розробників більш продуктивними, дозволяючи їм програмувати тією ж мовою та парадигмою OO, яку вони використовують у решті свого додатка. Збережені процедури не можуть цього передбачити, коли вони роблять код розробника мовою процедур, що зберігаються RDBMS. Тому вони не можуть зробити все, що може ORM.
— Білл Карвін

Відповіді:

53

Зробити доступ до даних більш абстрактним і портативним. Класи впровадження ORM знають, як писати специфічний для постачальника SQL, тому не потрібно.

— Білл Карвін
джерело
61
Хоча я погоджуюся, що це особливість ОРМ, я б запропонував, щоб випадок використання був досить обмеженим. Я ніколи не використовував нічого, окрім MySql та sqlite протягом декади. Я думаю, що це, мабуть, дуже рідкісна вимога до більшості розробників.
— troelskn
40
@troelskn: Я згоден, я використав багато RDBMS-продуктів, але ніколи більше одного-двох на проект. Тож портативність - не найпрактичніше значення абстрагування SQL. Я думаю, що багато користувачів ORM просто хочуть взагалі уникати кодування в SQL.
— Білл Карвін
2
Постачальники постійно виходять з новими версіями / функціями ... просто потрібні круті люди, щоб написати діалект і легко оновити його!
— dotjoe
5
Типова марна відповідь Цікаво, чому вона позначена як хороша відповідь, схоже, хлопець, який задає питання, просто спробуй виправдати своєму начальникові, що він повинен використовувати ORM :) Моє запитання, скоріше, з якою проблемою ти зіткнешся зі сплячим сном stackoverflow.com/questions/6477170 / ...
— user310291
2
@ user310291: ОП не запитувала проблем або підводних каменів, він попросив переваги використання ORM. Звичайно, є плюси і мінуси, але він попросив плюси. Відверто кажучи, я здивований, що ця відповідь була прийнята і отримала стільки результатів, скільки вона зробила, тому що я б не вважав це головною перевагою ORM.
— Білл Карвін
83

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

Один із типів запитів, про які я думаю, - це поліморфний запит. Простий запит ORM може вибрати всі фігури у вашій базі даних. Ви отримуєте колекцію фігур назад. Але кожен екземпляр - це квадрат, коло або прямокутник відповідно до його дискримінатора.

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

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

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

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

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

О так, деякі розробники вважають, що робота з ORM - це приємно, тому ORM також корисні з точки зору щастя ваших розробників. =)

— Чак
джерело
1
Добре сказано. Хоча в оригінальному плакаті було спеціально шукати "плюси", а не "мінуси", я бачив деякий HORRIBLE SQL, створений не розуміючи наслідків, яким чином ви використовуєте ORM. Для мене найбільша перевага полягає в простих транзакціях CRUD, які є більшістю вашого коду DAL для транзакційних систем. Я думаю, ви розділяєте волосся між чистими ORM та іншими створеними методами DAL. Я думаю, що все, що допоможе вам перекласти між об'єктами і БД, може вважатися ORM, це просто інша операційна модель.
— Даг Лампе
1
@Doug - Я думаю, що я відрізнявся від того, що простий DAL складався з трохи більше, ніж генерований CRUD SQL, тоді як ORM містив набагато більше абстракцій, таких як властивості навігації, збереження колекції, виділені мови запитів, кеші тощо. - Кращий спосіб Висловлюючи мою точку зору у вашому спостереженні, можливо, що хоча це правда, що використання більшої кількості функцій ORM дозволяє вам швидше реалізовувати, ні в якому разі не допустимо залишатися в курсі того, як ці функції працюють. Можливо, тому, що абстракції ОРМ витікають більше, ніж більшість. ( En.wikipedia.org/wiki/Leaky_abstraction )
— Чак,
будь ласка, детальніше зупиніться на цьому: "якщо ви не використовуєте більш вдосконалені функції запиту вашої ORM, існують інші варіанти, які вирішують інші проблеми". також, як каже творець сплячого режиму Гевін Кінг: "Дійсно, такі системи, як Hibernate, навмисно розроблені як" протікаючі абстракції ", щоб можна було легко перемішуватись у рідному SQL там, де це необхідно. Протікання абстракції ORM - це особливість, а не помилка. ! " - reddit.com/r/programming/comments/2cnw8x/…
— jungle_mole
1) Це старе. Тоді ORM мали всі функції (кеші, запити, групування тощо). Поліморфні запити на основі IMHO були єдиною функцією ORM, яку ген коду (явне відображення ADO) не міг легко надати. 2) Хоча навмисне залишилися деякі корисні дірки, були також необхідні зли та розширені функції, які створили високу криву навчання в ORM. Отже, моя відповідь полягала в тому, щоб використовувати gen code замість ORM, якщо вам не потрібні розширені запити. *) В даний час в ORM є достатньо різноманітності, що правильний набір функцій для вашої команди, ймовірно, там. Моя команда зараз захоплюється Linq2DB.
— Чак
60

Швидкість розвитку. Наприклад, усунення повторюваного коду, як-от відображення полів результатів запиту для об’єктів-членів, і навпаки.

— Білл Карвін
джерело
3
Код, що повторюється, дуже поганий, але чи не вдалося ви створити абстракцію, яка б це усунула? Наприклад, у вас може бути об’єкт результатів таблиці / запитів, який повертає вам рядки, з якими потім можна виконувати завдання. ORM, здається, розбивають рядки на окремі екземпляри класу, а не входять у вибрану БД абстракцію, яка є таблицями / рядками результатів запитів. Я не кажу, що це означає, що ORM не є хорошими, але я не впевнений, що це лише є причиною їх використання.
— Бенджон
@Benjohn, я погоджуюся, що рішення ORM розглядає окремі рядки як об'єкти, тоді як RDBMS розглядає набори рядків як сутність. У менструації RDBMS є те, що ви не можете зробити в умовному режимі OO.
— Білл Карвін
Це як купувати цілу машину просто для використання багажника, є багато способів уникнути повторюваної роботи
— mohas
15

Підтримка OO капсулювання бізнес-правил у вашому рівні доступу до даних. Ви можете писати (і налагоджувати) бізнес-правила на мові додатків, що надається вам, замість незграбних тригерів та збережених мов процедур.

— Білл Карвін
джерело
Ви не хочете, щоб правила вашого бізнесу були в базі даних? Це переваги бази даних, правда: кілька клієнтів можуть використовувати один і той же інтерфейс, що надається СУБД. Якщо багато вашої логіки інтерфейсу заблоковано в ORM-коді конкретного клієнта, його немає в базі даних, а інші клієнти не використовують його. Cue перерви на задній офіс (одна модель клієнта виходить за межі інших).
— Бенджон
1
@Benjohn, я схильний просто вносити бізнес-правила в базу даних, але складніші правила не легко формуються в декларативних обмеженнях. Наприклад, "замовник отримує 10% знижки на все замовлення, коли перший раз купує більше трьох пар блюд однієї марки". Як би ви ввели це правило бізнесу в базу даних (пам’ятайте, що відповідь, що стосується збережених процедур, незграбна).
— Білл Карвін
Настає 2020 рік, я більше не бачу нікого, хто використовує збережені процедури. Отже, ви вказуєте, що все ще стоїть?
— осіпдер
Думаю, моя думка полягає в тому, що люди не використовують збережені процедури, вони використовують код програми. Ви зрозуміли щось інше?
— Білл Карвін
10

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

— Білл Карвін
джерело
1
— Андрій Брекса
8

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

— Метт Фенелон
джерело
41
За 30 плюс років, як я працював з датами, мені не раз доводилося це робити.
— HLGEM
4
Це не означає, що це неможливо! :)
— Метт Фенелон
2
@HLGEM це означає, що ви закриваєте вибір для клієнта. Насправді це могло статися, лише за 3 роки роботи з веб-сайтами ми створили портативне програмне забезпечення за допомогою ORM
— Alfabravo
1
Це може бути корисним у випадку, якщо ви хочете запустити тести на базі даних пам'яті
— Carlos Parraga
Можливо, що кілька екземплярів одного програмного забезпечення можуть використовувати різні бази даних. Але насправді перенесення існуючих даних з одного програмного забезпечення на інший дійсно трапляється рідко. І коли це відбувається, багато ORM насправді не допомагають вам у цьому.
— jlh
4

Так що ваша об'єктна модель та модель стійкості збігаються.

— клетус
джерело
1
Можливо, так, щоб ваша наполегливість була прозорою для вашої об'єктної моделі
— С.Лотт
4

Щастя в розвитку, ІМО. ORM резюмує багато предметів з голого металу, які ви повинні зробити в SQL. Він забезпечує просту базу коду: менша кількість вихідних файлів для керування та зміни схем не потребують години обслуговування.

Зараз я використовую ORM, і це пришвидшило мою розробку.

— цікавий дідько
джерело
3

Причина, яку я розглядаю, полягає в тому, щоб уникнути згенерованого коду з інструментів DAL VS2005 (відображення схем, TableAdapters).

DAL / BLL, який я створив понад рік тому, працював чудово (для чого я його створив), поки хтось інший не почав ним користуватися, щоб скористатися деякими згенерованих функцій (про які я і гадки не мав)

Схоже, це забезпечить набагато більш інтуїтивне та чистіше рішення, ніж рішення DAL / BLL від http://wwww.asp.net

Я думав над тим, щоб створити власний генератор кодів SQL Command C # DAL, але ORM виглядає як більш елегантне рішення

— Ден Макклайн
джерело
2

Компіляція та тестування запитів.

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

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

Якщо ви використовуєте правильні шаблони доступу до даних у .NET, легко перевірити логіку запитів у колекціях пам'яті. Це пришвидшує виконання ваших тестів, тому що вам не потрібно отримувати доступ до бази даних, налаштовувати дані в базі даних або навіть розгортати повнорозмірний контекст даних. [EDIT] Це не так, як я вважав, що це одиниця тестування в пам’яті може представляти важкі труднощі для подолання. Але мені все ж здається, що ці тести на інтеграцію простіше написати, ніж у попередні роки. [/ EDIT]

Це, безумовно, більш актуально сьогодні, ніж кілька років тому, коли було задано питання, але це може бути лише справа Visual Studio і Entity Framework, де лежить мій досвід. Підключіть власне оточення, якщо можливо.

— Чак
джерело
1

Абстрагуйте sql далеко за 95% часу, тому не всі в команді повинні знати, як писати суперефективні запити для баз даних.

— Джаред
джерело
1

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

Зробіть кілька оцінок типових завдань (або навіть більших проектів, які можуть з’являтися), і ви (сподіваємось!) Отримаєте кілька аргументів для переключення, які важко ігнорувати.

— Андерс Фельдстад
джерело
0

.net яруси з використанням шаблонів кова Сміта

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Навіщо кодувати те, що може бути створено так само добре.

— Джобо
джерело
Тьфу. Ми використовували Net Tiers у великому комерційному проекті, і я б дуже радив не використовувати його. Проблема в тому, що вона не є композиційною. Хочете запитувати об’єкти Foo та Bar? Ви не можете писати приєднання, ви повинні видати окремі запити для кожного типу об'єкта, який ви хочете. Це призводить до безлічі дзвінків до бази даних, що може порушити продуктивність та атомність. Поганий, поганий, поганий. Тримайся подалі.
— Іуда Габріель Хіманго
0

переконайте їх, скільки часу / грошей ви заощадите, коли зміни прийдуть, і вам не доведеться переписувати свій SQL, оскільки інструмент ORM зробить це за вас

— zmf
джерело
0

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

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

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

— Шейлендра Сінгх Раджават
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.