Чи ORM є антидіаграмою? [зачинено]

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

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

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

• Невідповідність
  • Об'єктно-орієнтовані концепції
  • Різниці типів даних
  • Структурні та цілісні відмінності
  • Маніпулятивні відмінності
  • Трансакційні відмінності
• Вирішення невідповідності імпедансу
  • Мінімізація
  • Альтернативні архітектури
  • Компенсація
• Суперечка
• Філософські відмінності

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

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

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

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

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

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

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

Я б хотів би назвати щось "анти-візерунком", який вперше був названий зразком Мартіном Фаулером і з тих пір був застосований майже в кожній сучасній мові програмування. (Дивіться статтю Вікіпедії на ActiveRecord .)

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

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

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

Мій досвід: я використовую NHibernate з Linq2NHibernate.

Плюси:

• Він позбавляється від "Чарівних струн", або, принаймні, пропонує колись і єдине місце для їх розміщення
• Це дозволяє мені працювати в парадигмі OO весь час
• Код легше читати
• Код, вбудований зверху, легше змінити
• Це дозволяє обміняти фактичну реляційну базу даних без обслуговування 2 окремих сховищ (рідко робиться, але це одна велика перевага, якщо вона вам потрібна).

Мінуси:

• Код важче написати , тому що
• Це недостатня абстракція - ви все ще повинні бути глибоко знайомі з тим, що це робить на задньому плані

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

Якби я розпочав новий проект, я не впевнений, використовував би я ORM чи ні. Я , ймовірно , буду, але я не можу сказати напевно , ви повинні. Я б сказав, що це як різниця між вибором C ++ або Java / .NET для вашого проекту: чи вам буде потрібна гнучкість, яку ви отримуєте, працюючи на нижчому рівні, чи хочете скоріше працювати на більш високому рівні та (нібито) бути більше продуктивні? Нормальна відповідь - працювати на такому високому рівні, на який ви можете піти . Зазвичай це означає використання ORM.

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

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

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

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

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

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

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

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

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