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

11

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?
design-patterns architecture mvc code-quality linuxunil
la source
Cette question est similaire mais pas exactement la même .. softwareengineering.stackexchange.com/questions/180012/…
Jon Raynor
1
Cela pourrait intéresser. Est-il essentiel de créer une couche de service? et couche service vs DAO - Pourquoi les deux?
Laiv

Réponses:

7

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;)

Vladislav Rastrusny
la source
Si je comprends bien, il peut y avoir un problème technique en ce sens que si des mises à jour se produisent dans des fonctions / des processus stockés et également via un ORM, les états d'une transaction donnée sont très difficiles à raisonner. Bien que l'application puisse fonctionner dans son état actuel, un petit changement pourrait entraîner de très gros problèmes. Mon expérience avec Hibernate est que si vous ne le laissez pas gérer l'ensemble des tables avec lesquelles il fonctionne, vous aurez beaucoup de problèmes ennuyeux.
JimmyJames
réponse agréable et concise. SRP a été la première chose qui m'est venue à l'esprit lorsque j'ai regardé le code pour la première fois. Certains collègues affirment que la méthode ne viole pas SRP car elle n'appelle que la fonction de base de données. Mais certaines de ces fonctions font des sélections, des insertions et des mises à jour. Donc, cela ne viole pas ou non le SRP? (peut-être que c'est une autre question à discuter séparément?)
linuxunil
1
+1 pour cette ligne, je pense que dans notre monde, tout se passe;)
linuxunil
@linuxunil SRP doit être respecté à tous les niveaux de l'architecture. Dans mon cas, je voulais dire SRP au niveau du service, pas au niveau de la méthode. @ JimmyJames Yep. La plupart des ORM ne fonctionnent pas bien avec les procédures stockées. Mais parfois, des processus stockés sont nécessaires.
Vladislav Rastrusny,
3

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.

J. Pichardo
la source
Je ne sais pas pourquoi cela a été rejeté. Cette réponse recommande de séparer le code qui traite de différentes préoccupations . On dirait un principe de programmation ici ... je ne sais pas ce que c'est ... Man. Si seulement je pouvais penser au nom. +1 BTW
Greg Burghardt
N'est-ce pas l'un des principes solides?
J. Pichardo du
3
Non , le "S" à l'état solide est le S Ingle principal de responsabilité (SRP). Mais la séparation des préoccupations, que vous recommandez, est une raison valable pour séparer la logique de service de la logique d'accès aux données. L'autre réponse de Vladislav mentionne le principe de responsabilité unique. Franchement, le PÉR et la séparation des préoccupations vont bien ensemble, comme le vin et le fromage.
Greg Burghardt