Pourquoi MVC4 utilise-t-il le Localisateur de Service Anti-Pattern?
Après avoir lu "Dependency Injection in. Net" par Mark Seemann, je reste à l'écart du Localisateur de Service qui est un anti-pattern.
En lisant les notes de version sur MVC 4 je vois:
Amélioration de L'Inversion du contrôle (IoC) via DependencyResolver: API Web utilise maintenant le modèle de localisateur de service implémenté par la dépendance de MVC résolveur pour obtenir des instances pour de nombreuses installations différentes.
Ainsi je suis laissé curieux et confus Pourquoi Microsoft utiliserait un localisateur de service en 2012.
2 réponses
C'est un détail d'implémentation dont vous ne devriez pas vous soucier. L'important est que maintenant que L'API Web utilise DependencyResolver pour résoudre les dépendances de nombreuses installations différentes, vous serez en mesure d'utiliser une véritable injection de dépendance chaque fois que vous voulez vous connecter à ces installations. Donc, dans votre code, vous utiliserez une véritable injection de dépendance. Si Microsoft n'a pas utilisé le DependencyResolver alors c'est vous qui avez dû l'utiliser (en tant qu'anti-pattern de localisateur de service) dans votre code afin de résoudre les dépendances lorsque vous souhaitez implémenter des fonctionnalités personnalisées. Cela aurait été mauvais pour vous. Maintenant, c'est mauvais pour Microsoft mais vous ne vous souciez pas d'eux.
Ainsi, je suis laissé curieux et confus pourquoi Microsoft utiliserait un localisateur de service en 2012.
, Car la conception d'un framework n'est pas la même que la conception d'une application à l'aide d'un cadre. Il y a différentes choses à prendre en considération lors de la conception d'un cadre réutilisable tel que ASP.NET MVC plutôt que ce qui est écrit dans les livres. Un exemple est de concevoir le cadre de telle sorte qu'une personne utilisant ce cadre sera en mesure de tirer parti des meilleures pratiques écrites dans les livres dans son code en utilisant ce cadre.
Comme le souligne Darin, ASP.NET MVC 4 est un Framework et est agnostique conteneur. C'est pourquoi il fournit un localisateur de service sous la forme de IDependencyResolver. Cela permet à quiconque de brancher leur conteneur de choix.
Cependant, je n'appellerais pas cela un motif anti. Cela vous permet d'utiliser le conteneur de votre choix, mais cela ne force pas Vous le développeur de l'application à utiliser l'emplacement du service. Si le framework obligeait le développeur à utiliser L'emplacement du Service, alors je l'appellerais un anti-modèle. Mais le développeur qui construit un ASP.NET l'application MVC est libre d'utiliser DI via l'injection du constructeur, la configuration de la propriété ou l'emplacement du service. C'est leur choix.
Regardez tous les ASP.NET MVC exemples d'injection de dépendance publiés par moi ou le ASP.NET équipe MVC. Dans presque tous les cas, ils utilisent l'injection constructeur. Ils n'utilisent pas l'emplacement du service.
En fait, la plupart des ASP.NET le code source MVC lui-même n'utilise pas l'emplacement du service pour récupérer dépendance. Il y a quelques endroits clés où le MVC appelle dans le Localisateur de service pour les API héritées et autres. Mais c'est tout.