Couche de service d'application appelant des fonctions de base de données. Mauvaise architecture?

Scénario:

• Pile: Java, Spring, Hibernate.
• Modèle: application client-serveur.
• Modèle: Model-View-Controller (MVC).

Les classes Service Layer ont trois comportements:

1. Certains services ont la règle métier dans les méthodes et délèguent la persistance à l'application. Comme:

   EntityManager.save (entité);

2. Certains services appellent simplement une fonction de base de données (en passant des paramètres) comme:

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

3. Certains services ont des méthodes avec les deux comportements.

Mes questions:

1. Y a-t-il un problème à ce que les services d'application appellent - directement - les fonctions de la base de données? N'est-ce pas considéré comme une mauvaise pratique? Quel serait un modèle d'architecture applicable à un projet comme celui-ci?
2. Y a-t-il un problème à avoir la combinaison de comportements dans le même service? Telles que les transactions et la cohérence?
3. Dans le cas de la maintenance, cette encapsulation fait-elle oublier au développeur qu'il doit également modifier les fonctions de la base de données? Comment éviter cela?
4. Ce scénario se produit-il dans d'autres applications à travers le monde ou s'agit-il simplement d'une erreur architecturale?

Y a-t-il un problème à ce que les services d'application appellent - directement - les fonctions de la base de données? N'est-ce pas considéré comme une mauvaise pratique?

Je pense que oui. Vous placez une connaissance des éléments internes de la base de données dans le service d'application. Changer la base de données de quelque manière que ce soit (changer le moteur de stockage ou même renommer un champ ou créer un index) peut vous obliger à changer de service d'application et cela viole SRP .

Quel serait un modèle d'architecture applicable à un projet comme celui-ci?

Voir le commentaire ci-dessous.

Y a-t-il un problème à avoir la combinaison de comportements dans le même service? Telles que les transactions et la cohérence?

Je ne pense pas qu'il y ait un problème technique, mais il y a un problème logique. Vous mélangez simplement deux approches dans l'application, ce qui la rend vague, moins structurée, difficile à adapter aux changements. Voir les commentaires ci-dessus sur la violation de SRP également.

Dans le cas de la maintenance, cette encapsulation fait-elle oublier au développeur qu'il doit également modifier les fonctions de la base de données?

Bien sûr.

Comment éviter cela?

Placez des méthodes et des fonctions qui fonctionnent directement avec la base de données dans un niveau d'abstraction distinct (que ce soit une couche DAO ou un modèle de référentiel simple - cela dépend de la complexité de votre application)

Ce scénario se produit-il dans d'autres applications à travers le monde ou s'agit-il simplement d'une erreur architecturale?

Je pense que dans notre monde tout se passe;)

Selon ce que vous avez dit, il existe une couche de service, donc le modèle architectural qui semble approprié est l'architecture en couches. Référence supplémentaire

Oui, c'est généralement une mauvaise pratique de faire des appels directs à la base de données sur une couche autre qu'une couche d'accès aux données, de cette façon la couche métier n'accède qu'à une abstraction de la base de données.

En ce qui concerne les comportements de mélange, l'utilisation d'un modèle de conception comme modèle DAO ou modèle de référentiel pourrait aider à déléguer ces responsabilités, améliorant ainsi ce code.

Certains des avantages de l'utilisation d'un modèle de conception et d'un ORM sont la lisibilité de votre code, l'encapsulation des responsabilités, donc si l'accès à votre base de données change, votre couche métier ne devrait pas changer grand-chose.