Чи закінчився вік логіки домену в базах даних? [зачинено]


9

Нещодавно я наткнувся на цю думку від 2016 року, сказавши, що все ще існує справа в логіці домену в базі даних.

Я подумав, що це абсолютно застаріло. Мені просто цікаво, чи хлопець все ще живе в 90-х, чи це може бути справді правдою. Відкладіть застарілі системи.

А що з логікою домену в базі даних через вимоги безпеки. Це справді щось робити?


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

Так, він закрився 18 лютого 2009 року і тепер є помилковим.
Майкл Дюрант

Це цікаво. Я читав цього хлопця, даючи безліч прикладів SQL (сильно прив’язаний до Oracle), а потім не можу не згадати, як мій клієнт сказав мені: я забув придбати ліцензію Oracle для PRE env. Ми маємо це для PRO, але не для PRE. Вам доведеться на деякий час розгорнути додаток, проти MySQL в PRE та Oracle в PRO ... Я попрошу цього хлопця, куди зараз діють усі шикарні функції Oracle ... (Проблема тут полягала в тому, що це було чомусь Я не хочу знати, архітектор вирішив перейти до рідного Sql - шляху відображення рядків замість Orm, але все ще близький до проблеми заблокування до постачальника БД) .
Лаїв

@Laiv: Це божевільно, і жодна кількість ORM чи інших абстракцій не врятує вас. Ви в основному використовуєте неперевірений код для виробництва з таким налаштуванням.
ЖакБ

2
"Чи закінчився вік логіки домену в базах даних?" Боже, я сподіваюся, що так.
обідне м’ясо317

Відповіді:


13

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

Візьмемо, наприклад, блог чистого кодування Боба Мартіна. Як загальне спостереження, я вважаю, що праці Боба Мартіна є досить чіткими і зрозумілими, тому мене бентежить, що люди постійно плутаються з написаними ним речами, такими як принципи SOLID. Вони зациклюються на тому, якою має бути "Єдина відповідальність", або чому якийсь клас порушує принципи Ліскова, коли те, що вони, ймовірно, повинні робити, - це просто прагнути написати кращий код і спочатку отримати досвід, щоб те, що вони читали в блоги мають певний контекст.


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

У статті цитуються такі речі:

  • Цілісність та валідація даних (наприклад, нульові та унікальні обмеження)
  • Рівень безпеки
  • Написання API з використанням збережених процедур
  • Розрахунок залишків
  • Задавання запитань до бази даних (тобто запитів і звітів)
  • Уникнення проблем з ORM, таких як N + 1

як підходящі речі для введення в базу даних. Я випадково погоджуюся з ним.

Причини, коли ви не вкладаєте бізнес-логіку (загалом) у базу даних:

  • Блокування провайдера
  • Ваша база даних не є центральним органом
  • Ваша команда не мислить відносно
  • Недосконалі інструменти.

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

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


3
Дуже хороша розбивка та кращий спосіб вирішити питання.
candied_orange

9

введіть тут опис зображення

Вік коня та баггі закінчився, але ви все ще можете придбати баггі батогів.

Чому? Коли машини швидше, дешевше в обслуговуванні, а їх нехтування не призведе до відвідувань гуманного суспільства, чому кінь та візок все ще існують?

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

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

Мій особистий погляд:

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

З іншого боку, хто сказав, що база даних не може мати поведінку? Я створив офісні бази даних за допомогою Filemaker. Люди називають це базою даних, але це також ціле середовище розробки додатків. Все легко інтегрується в одне ціле і називається базою даних.

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

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

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


1
Ваша відповідь звучить, що ви навіть не заглянули у статтю, пов’язану з ОП (не те, що я кажу, що автор є правильним чи неправильним), але чи можете ви сказати нам, де ви згодні чи відрізняєтесь від поглядів, описаних у цій статті?
Doc Brown

@DocBrown я також не читав, але ця відповідь все одно хороша, де я повністю погодився. І він звертається в OP ще питання (останнє речення), а не наведено назву статті.
qwerty_so

@DocBrown Я не думаю, що стаття читала статтю дядька Боба, яку вона цитує : "Архітектури плагінів дуже надійні, оскільки стабільні правила високого значення для бізнесу можуть бути збережені залежно від мінливих модулів з низьким значенням, таких як інтерфейси користувачів та бази даних." Дядько Боб має більш сильні погляди проти цієї ідеї, ніж я. Ця стаття вишня вибирає із статті Боба, і здається, що Боб говорить щось, чого він не робить.
candied_orange

2

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

Наша концепція безпеки OO-програми складається з ролей ТА груп. І те й інше є рекурсивними структурами. Ми написали збережену процедуру, яка вирішує дозвіл користувача на об’єкт домену.

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

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