Уровень приложений, вызывающий функции базы данных. Плохая архитектура?

Сценарий:

• Стек: Java, Spring, Hibernate.
• Модель: клиент-серверное приложение.
• Шаблон: Модель-Вид-Контроллер (MVC).

Классы Service Layer имеют три поведения:

1. Некоторые сервисы имеют бизнес-правило внутри методов и делегируют постоянство приложению. Подобно:

   EntityManager.save (юридическое лицо);

2. Некоторые сервисы просто вызывают функцию базы данных (передавая параметры)

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

3. Некоторые сервисы имеют методы с обоим поведением.

Мои вопросы:

1. Есть ли проблема в том, чтобы прикладные службы вызывали функции базы данных напрямую? Разве это не считается плохой практикой? Какая модель архитектуры будет применима к такому проекту?
2. Есть ли какая-либо проблема в том, что поведение поведения в одной и той же службе? Такие как транзакции и последовательность?
3. В случае обслуживания, делает ли эта инкапсуляция неясным для разработчика, что он также должен изменить функции в базе данных? Как этого избежать?
4. Этот сценарий встречается в других приложениях по всему миру или это просто архитектурная ошибка?

Есть ли проблема в том, чтобы прикладные службы вызывали функции базы данных напрямую? Разве это не считается плохой практикой?

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

Какая модель архитектуры будет применима к такому проекту?

Смотрите комментарий ниже.

Есть ли какая-либо проблема в том, что поведение поведения в одной и той же службе? Такие как транзакции и последовательность?

Я не верю, что есть техническая проблема, но есть логическая. Вы просто смешиваете два подхода в приложении, делая его расплывчатым, менее структурированным, трудным для адаптации к изменениям. Смотрите комментарии выше о нарушении SRP также.

В случае обслуживания, делает ли эта инкапсуляция неясным для разработчика, что он также должен изменить функции в базе данных?

Конечно, это так.

Как этого избежать?

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

Этот сценарий встречается в других приложениях по всему миру или это просто архитектурная ошибка?

Я думаю, что в нашем мире все происходит;)

Согласно тому, что вы сказали, есть сервисный слой, поэтому архитектурный шаблон, который кажется подходящим, это многоуровневая архитектура. Дальнейшая ссылка

Да, обычно плохая практика - делать прямые обращения к базе данных не на уровне доступа к данным, а на бизнес-уровне только для доступа к абстракции базы данных.

Что касается поведения смешивания, использование некоторого шаблона проектирования в качестве шаблона DAO или шаблона репозитория может помочь делегировать эти обязанности, тем самым улучшая этот код.

Одним из преимуществ использования шаблона проектирования и ORM является удобочитаемость вашего кода, инкапсуляция обязанностей, поэтому, если доступ к вашей базе данных изменится, ваш бизнес-уровень не должен сильно измениться.