Після використання Hibernate в більшості моїх проектів протягом близько 8 років я приземлився на компанію, яка відмовляє від його використання і хоче, щоб програми взаємодіяли з БД тільки через збережені процедури.
Зробивши це протягом декількох тижнів, мені не вдалося створити багату доменну модель програми, яку я починаю створювати, і додаток просто схожий на (жахливий) сценарій транзакцій.
Деякі проблеми, які я знайшов:
- Не вдається переміститися по графіку об'єктів, оскільки збережені процедури просто завантажують мінімальну кількість даних, це означає, що іноді ми маємо подібні об'єкти з різними полями. Один із прикладів: у нас є збережена процедура для отримання всіх даних від клієнта, а інша для отримання інформації облікового запису плюс кілька полів від клієнта.
- Багато логіки виявляється в допоміжних класах, тому код стає більш структурованим (з сутностями, що використовуються як старі структури С).
- Більш нудний код лісу, оскільки немає рамки, яка витягує набори результатів із збереженої процедури та розміщує їх у сутності.
Мої запитання:
- хтось був у подібній ситуації і не погоджувався з підходом до процедури магазину? що ти зробив?
- Чи є фактична користь від використання збережених процедур? крім дурної точки "ніхто не може видати стіл для крапель".
- Чи є спосіб створити багатий домен, використовуючи збережені процедури? Я знаю, що існує можливість використання AOP для введення DAO / Repositories в об'єкти, щоб мати можливість переміщатися по об’єктовому графіку. Мені не подобається цей варіант, оскільки він дуже близький до вуду.
Висновок
По-перше, дякую всім за відповіді. Висновок, що я прийшов, полягає в тому, що ORM не дозволяють створювати моделі Rich Domain (як дехто згадував), але це спрощує кількість (часто повторюваної) роботи. Далі йде більш детальне пояснення висновку, але воно не ґрунтується на жодних важких даних.
Більшість програм запитують та надсилають інформацію в інші системи. Для цього ми створюємо абстракцію в модельних термінах (наприклад, ділова подія) і модель домену надсилає або отримує подію. Заходу зазвичай потребує невеликого підмножини інформації від моделі, але не всієї моделі. Наприклад, в інтернет-магазині шлюз платежів вимагає певної інформації користувача та загальної суми для стягнення плати за користувача, але не вимагає історії покупки, наявних продуктів та всієї клієнтської бази. Тож подія має невеликий і специфічний набір даних.
Якщо ми сприймаємо базу даних програми як зовнішню систему, тоді нам потрібно створити абстракцію, яка дозволяє нам відображати об'єкти Доменної моделі в базі даних ( як згадував НімЧимпський , використовуючи картограф даних). Очевидна відмінність полягає в тому, що зараз нам потрібно здійснити картування для кожної модельної сутності до бази даних (або застаріла схема, або збережені процедури), з додатковим болем, що, оскільки вони не синхронізовані, одне об'єднання домену може частково відобразити карту на сутність бази даних (наприклад, клас UserCredentials, який містить лише ім'я користувача та пароль, відображається в таблиці користувачів, у якій є інші стовпці), або один об'єкт моделі домену може відображатись на більш ніж один об'єкт бази даних (наприклад, якщо є один-до- одне відображення на таблиці, але ми хочемо, щоб усі дані були лише в одному класі).
У заявці з кількома сутностями кількість зайвих робіт може бути невеликою, якщо немає необхідності перетинати сутності, але вона збільшується, коли є необхідна умовна перетинання сутностей (і, таким чином, ми можемо захотіти реалізувати якусь "ледачу" завантаження '). Оскільки додаток зростає до більшої кількості сутностей, ця робота просто збільшується (і я відчуваю, що вона збільшується нелінійно). Моє припущення, що ми не намагаємось винаходити ORM.
Однією з переваг трактування БД як зовнішньої системи є те, що ми можемо кодувати ситуації, в яких ми хочемо, щоб дві різні версії програми працювали, в яких кожна програма має різне відображення. Це стає більш цікавим у сценарії постійних поставок у виробництво ... але я думаю, що це можливо і в менших масштабах з ОРМ.
Я збираюся відхилити аспект безпеки, виходячи з того, що розробник, навіть якщо він не має доступу до бази даних, може отримати більшість, якщо не всю інформацію, що зберігається в системі, просто ввівши шкідливий код (наприклад, Не можу повірити, що я забув видалити рядок, який записує реквізити кредитних карток клієнтів, шановний пане! ).
Невелике оновлення (6.06.2012)
Збережені процедури (принаймні в Oracle) заважають робити щось подібне до постійної доставки з нульовим простоєм, оскільки будь-яка зміна структури таблиць призведе до недійсності процедур і тригерів. Тож під час оновлення БД програма також буде вимкнена. Oracle надає рішення для цієї назви Визначення на основі редакції , але нечисленні DBA, про які я запитував про цю функцію, згадували, що вона мала слабке враження, і вони не вкладають її у виробничу БД.