dependency-injection - net - unity container web api 2
¿Por qué MVC4 usa el Localizador de servicios antipatrón? (2)
Después de leer "Dependency Injection in .NET" de Mark Seemann, me mantengo alejado del Localizador de servicios, que es un antipatrón.
Al leer las notas de la versión en MVC 4 , veo:
Mejora de la inversión de control (IoC) a través de DependencyResolver: Web API ahora usa el patrón de localizador de servicios implementado por el resolvedor de dependencias de MVC para obtener instancias para muchas instalaciones diferentes.
Por lo tanto, me queda curioso y confundido por qué Microsoft usaría un localizador de servicios en 2012.
Como señala Darin, ASP.NET MVC 4 es un Framework y es independiente del contenedor. Es por eso que proporciona un localizador de servicios en forma de IDependencyResolver . Esto permite que cualquier persona conecte su contenedor de su elección.
Sin embargo, no llamaría esto un patrón anti. Esto le permite usar el contenedor de su elección, pero no le obliga al desarrollador de la aplicación a usar la ubicación del servicio. Si el marco obligó al desarrollador a utilizar la ubicación del servicio, entonces lo llamaría un antipatrón. Pero el desarrollador que crea una aplicación ASP.NET MVC puede usar DI de forma gratuita a través de la inyección del constructor, la configuración de la propiedad o la ubicación del servicio. Es su elección.
Mire todos los ejemplos de ASP.NET MVC de inyección de dependencia publicados por mí o por el equipo ASP.NET MVC. En casi todos los casos, están usando inyección de constructor. No están usando la ubicación del servicio.
De hecho, la mayoría del código fuente ASP.NET MVC no usa la ubicación del servicio para recuperar dependencias. Hay algunos lugares clave donde el MVC llama al localizador de servicios para API heredadas y demás. Pero eso es todo.
Es un detalle de implementación que no debería importarle. Lo importante es que ahora que la API web usa DependencyResolver para resolver las dependencias de muchas instalaciones diferentes, podrá usar una inyección de dependencia real cada vez que quiera conectarse a esas instalaciones. Entonces en tu código usarás una inyección de dependencia real. Si Microsoft no usó DependencyResolver entonces debió haberlo usado (como un antipatrón de localizador de servicios) en su código para resolver dependencias cuando desea implementar alguna funcionalidad personalizada. Esto hubiera sido malo para ti . Ahora es malo para Microsoft, pero a usted no le importan.
Por lo tanto, me queda curioso y confundido por qué Microsoft usaría un localizador de servicios en 2012.
Porque diseñar un marco no es lo mismo que diseñar una aplicación usando un marco. Hay algunas cosas diferentes a tener en cuenta al diseñar un marco reutilizable como ASP.NET MVC en lugar de solo lo que está escrito en los libros. Un ejemplo es diseñar el marco de tal manera que una persona que use este marco pueda aprovechar las mejores prácticas escritas en los libros en su código usando este marco.