Discussion :

[SyntaxErrorAtLine4]

Bonjour à tous,

Cela fait un petit moment que cette question me taraude ... Mais je ne l'ai jamais posée.

Imaginons que l'on mette en place une architecture multi-tiers pour une application Web quelconque. On a donc la couche de présentation, la couche métier et enfin la couche d'accès aux données.

Faisons un petit focus sur la couche métier ... Imaginons que l'on possède les deux services suivants :

1. un service de gestion d'envoi d'email (du genre mise en file d'attente et envoi par lot dans la nuit) ;
2. un service de création d'utilisateur.

Rien de bien folichon. Imaginons maintenant que la règle est que lorsqu'un utilisateur est créé, un mail lui est envoyé ... Les deux services cités précédemment sont impactés.

Ma question est donc la suivante ... Quel est la conception la plus intelligente de la couche métier ? A mes yeux, il y a 3 solutions :

1. utilisation d'un registre de service (ServiceLocator) ;
2. IoC directement dans les services (un service contient une référence vers les autres services dont il dépend) ;
3. une pseudo-couche supplémentaire qui regroupe tout les services, dans laquelle on applique la règle (une sorte de Facade en quelque sorte).

Je ne suis convaincu par aucune de ces approches (d'où ma question ) ... Chais pas ... Y a un truc qui ne va pas. Qu'en pensez vous ? Comment avez vous résolu une telle situation ?

Merci beaucoup pour vos réactions !

A.

[janselmeer]

Je dirais 2 ou 3 suivant le contexte.
Comme souvent il s'agit d'un compromis entre cout de développement et maintenabilité.

Si il s'agit d'une petite application avec des règles simples alors la solution 2 suffit.
Sinon, la solution 3 est préférable. La couche service se décompose alors en 2 niveaux. D'une part des services de bas niveaux indépendants qui réalisent une opération unitaire, qui sont stables dans le temps et réutilisables. D'autre part des services d'orchestration qui implémentent les traitements (règles) métiers en enchaînant les services de bas niveau, et qui peuvent évoluer souvent.

Personnellement, je préconise la solution 3 par défaut depuis que j'ai découvert les immondes tas de spaghettis de services que m'ont laissés certains développeurs avec la solution 2.

[SyntaxErrorAtLine4]

Merci beaucoup pour ta réponse.

En fait, c'est ce que j'utilise aussi ... Une couche de Façade qui permet de mixer les services. En plus, il est du coup possible de spécialiser ces façades en fonctions des acteurs qui vont l'utiliser (que ce soit des utilisateurs (i.e. Administrateur, ou autre) ou bien une machine (genre un scheduleur externe ou je sais pas quoi).

Mais du coup, y a un soucis (en fait c'est ça qui me dérange). Certains services sont transverses à toutes ces façades et je pourrais même aller plus loin en disant qu'ils sont transverse à tous les projets :

1. logging ;
2. configuration ;
3. validation ;
4. ...

Du coup ... D'après le peu que j'ai lu, le plus propre est de s'orienter pour ce genre de choses assez particulière vers l'AOP, qui permet d'avoir encore plus d'abstraction.

Qu'en penses-tu ?

[janselmeer]

Oui, le mieux pour les services transverses c'est d'utiliser l'AOP.
C'est ce que je fais moi et je trouve cela indispensable. Sans AOP, il faudrait dupliquer beaucoup de code avec les risques que cela comporte.

Je te conseille donc d'approfondir le sujet, cela vaut vraiment le coût.