Службовий рівень програми виклику функцій бази даних. Погана архітектура?

Сценарій:

• Стек: Java, весна, сплячка.
• Модель: Клієнт-серверна програма.
• Шаблон: Контролер перегляду моделі (MVC).

Класи службового шару мають три форми поведінки:

1. Деякі служби мають ділове правило в рамках методів і делегують наполегливість додатку. Подібно до:

   EntityManager.save (сутність);

2. Деякі служби просто викликають функцію бази даних (передаючи параметри).

   CallableStatement cls = con.prepareCall ("{call databaseFunction (args)}");

3. Деякі служби мають методи з обома способами поведінки.

Мої запитання:

1. Чи є якісь проблеми у тому, щоб служби додатків безпосередньо викликали функції бази даних? Чи не вважається це поганою практикою? Якою буде модель архітектури, застосовною до такого проекту?
2. Чи є якась проблема в поєднанні поведінки в одній службі? Такі як транзакції та послідовність?
3. Що стосується технічного обслуговування, чи робить це капсулювання незрозумілим для розробника, що він також повинен змінювати функції в базі даних? Як цього уникнути?
4. Чи трапляється цей сценарій в інших програмах по всьому світу чи це була лише архітектурна помилка?

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

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

Якою буде модель архітектури, застосовною до такого проекту?

Дивіться коментар нижче.

Чи є якась проблема в поєднанні поведінки в одній службі? Такі як транзакції та послідовність?

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

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

Звичайно, це так.

Як цього уникнути?

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

Чи трапляється цей сценарій в інших програмах по всьому світу чи це була лише архітектурна помилка?

Я думаю, що в нашому світі все відбувається;)

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

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

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

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