Classes de gestion

Question

Dans un projet récent, j'ai presque terminé, nous avons utilisé une architecture qui, en tant que couche supérieure d'interaction des couches web/services, utilise les classes XXXManager. Par exemple, il existe un service Windows qui s'exécute de manière planifiée et qui importe des données provenant de plusieurs sources de données diverses dans notre système. Au sein de ce service, plusieurs classes "Manager" sont appelées par exemple CPImportScheduleManager, CPImportProcessManager, etc.

Maintenant, ces classes Manager font beaucoup plus que simplement passer la méthode à la chaîne pour l'utiliser dans les couches web/service. Par exemple ma méthode UserManager.Register() ne persiste pas seulement à l'utilisateur via des assemblages de niveau inférieur mais envoie aussi un push WAP à l'utilisateur et détermine le combiné mobile utilisé, etc.

Il m'a été suggéré que ceci type d'architecture I un moyen courant d'essayer d'intégrer la POO dans un modèle procédural. Je peux voir leur point ici, mais ce que je me demande, c'est qu'avec ce jeu de classes de niveau supérieur, toute couche web/service peut simplement appeler la même méthode commune sans avoir à réécrire le code. Ainsi, si je voulais écrire un service web qui à un moment donné a enregistré un utilisateur, je pourrais à nouveau appeler la méthode UserManager.Register() sans avoir à réécrire toute la logique.

Je n'ai jamais été la meilleure personne pour m'expliquer, mais si mes divagations ont du sens, n'hésitez pas à nous conseiller sur vos alternatives.

Cheers, Chris.

Answer 1

Les gestionnaires sont une stratégie de dénomination communément utilisée pour les services qui gèrent le flux de travail ou les tâches complexes pour un ensemble donné d'entités. Cependant, si le travail est fait, ce n'est pas nécessairement une mauvaise chose.

La question importante que je voudrais savoir est ce qui se passe sous les gestionnaires? S'ils sont simplement coordonnés le flux de travail d'un processus, tel que l'enregistrement d'un utilisateur, alors ils sont des contrôleurs (MVC) avec un nom différent. Cependant, s'ils contiennent beaucoup de logique métier (j'entends par là une logique conditionnelle dépendant de l'état d'une entité ou d'un ensemble d'entités), alors je ferais attention de voir si vous pouvez rendre cette logique explicite en la rendant propre classe ou de le déplacer à la classe avec la responsabilité appropriée.

Mise à jour: Du son, vous avez une bonne idée en général. Vous disposez d'un ensemble de classes qui gèrent la coordination de vos processus métiers, peu importe qu'ils soient utilisés par un WebService, un Webform ou autre. Ensuite, vous dites que vous voulez ajouter votre couche WebService et utiliser ces classes. C'est une bonne chose (tm).

Answer 2

On dirait que votre motivation pour ce design était bonne - la réutilisation du code. D'une certaine manière, sa motivation est similaire à Martin Fowler's Service Layer. Cependant, vous pouvez empiler trop de responsabilités dans ces classes Manager. Peut-être des préoccupations d'infrastructure distinctes (push WAP, persistance de l'utilisateur) des préoccupations de domaine (enregistrement de l'utilisateur). Ce Separation of Concerns augmenterait encore la réutilisation et améliorerait la maintenabilité.