Utilisation de l'unité pour découpler la couche logique métier de la couche d'accès aux données

Question

J'ai implémenté Unity dans mon projet Asp.Net MVC2. J'inscris actuellement mes types de BLL sur Application Start.

Puis j'ai créé une classe appelée UnityControllerFactory chargée de résoudre mes dépendances dans mes contrôleurs. J'utilise simplement l'injection de propriété pour accomplir ceci en utilisant l'attribut de dépendance. Je pense ensuite à supprimer les dépendances contenues dans mes classes BLL qui sont liées à l'implémentation concrète des classes de couche DAL. Je voudrais également pouvoir le faire via l'injection de propriété au lieu de l'injection de constructeur puisque je référence plusieurs classes dans mes méthodes de classe Bll.

J'espérais des conseils sur toutes les solutions disponibles pour résoudre ce problème ou est-ce complètement exagéré?

Answer 1

Si vos classes BLL sont créées par Unity, alors cela ne va pas poser de problème, le conteneur fournira simplement les dépendances requises par les classes BLL lors de leur création. Si ce n'est pas le cas, alors vous allez rencontrer un problème, simplement parce que d'une manière générale, l'objet qui crée votre classe BLL devrait également fournir ses dépendances. Cependant, je voudrais vous mettre en garde sur l'utilisation de l'injection basée sur la propriété. La règle générale dans le monde de l'injection de dépendances est que les dépendances requises doivent être injectées via le constructeur, tandis que les dépendances facultatives doivent être injectées via les propriétés. Si votre classe a besoin d'une autre classe pour faire son travail, il ne devrait pas y avoir moyen de créer une instance de la classe sans avoir aussi ses dépendances requises.

Vous avez mentionné l'utilisation de l'injection de propriétés en raison du nombre de dépendances dans vos classes BLL. Bien que je comprenne cela, je pense qu'il est toujours essentiel de suivre la règle requise = constructor. Si vous vous retrouvez avec un constructeur qui a trop de dépendances, alors c'est une odeur de code qui pointe vers un problème quelque part dans votre conception. Il se peut que la classe assume trop de responsabilités (c'est généralement le cas si vous trouvez que certaines méthodes nécessitent un groupe de dépendances, tandis qu'un autre groupe nécessite un ensemble différent). Il se peut également que le travail effectué avec les dépendances soit trop granulaire et puisse être enveloppé dans un autre objet qui pourrait coordonner le travail des classes dépendantes.