¿Por qué MVC4 usa el Localizador de servicios antipatrón?

Después de leer "Dependency Injection in .NET" por Mark Seemann me mantengo alejado del Service Locator que es un antipatrón.¿Por qué MVC4 usa el Localizador de servicios antipatrón?

Al leer the release notes on MVC 4 veo:

Mejora de Inversión de Control (IoC) a través de DependencyResolver: Web API ahora utiliza el patrón de servicio de localización implementado por la dependencia resolución de MVC para obtener instancias para muchas instalaciones diferentes.

Así me quedo curioso y confundido por qué Microsoft podría utilizar un localizador de servicios en 2012.

Fuente

2012-02-23 Tom Stickel

Eso es un detalle de implementación que usted no debe preocuparse. 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ó el DependencyResolver, entonces habría sido usted quien lo debería haber usado (como un anti-patrón de localizador de servicio) en su código para resolver dependencias cuando quiera implementar alguna funcionalidad personalizada. Esto hubiera sido malo para usted. Ahora es malo para Microsoft pero no le importan.

Así me quedo curioso y confundido por qué Microsoft podría utilizar un localizador de servicios en 2012.

Debido a que el diseño de un marco no es el mismo que el diseño de una aplicación que utiliza 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.

Fuente

2012-02-23 07:59:56

+1 Los marcos siguen reglas diferentes que las aplicaciones.Desea mantener un agnóstico de contenedor de marcos (en el caso de que una aplicación que quiera usar el framework ya use un contenedor diferente) y generalmente no desea aplicar el uso de DI en esas aplicaciones (ya que es posible que no quieran usar DI en absoluto). –

+23

No compro el argumento de que solo porque es un marco, un localizador de servicios es apropiado. Sí, los marcos son diferentes a las aplicaciones, pero es perfectamente posible escribir un marco sin usar un Localizador de servicios. Basta con mirar ASP.NET MVC 1 y 2, o incluso algo tan complejo como WCF. El problema con DependencyResolver en ASP.NET MVC 3+ es que no se trata solo de un detalle de implementación interna, sino que se publica y promociona como 'soporte DI' público. –

@MarkSeemann Tuve esta discusión con el arquitecto jefe de un gran marco empresarial. Si puede decirme cómo hacer que dicho contenedor sea independiente del contexto y no aplicar el patrón DI en todas las aplicaciones que se escriben usando ese marco, estaría más que contento de escucharlas. –

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 a esto un patrón anti. Esto le permite usar el contenedor de su elección, pero no forza el desarrollador de la aplicación para 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 de 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.

Fuente

2012-03-12 16:09:07 Haacked

Parece razonable, todavía me pregunto por qué recibí esta respuesta de parte de Marcin Dobosz (http://blogs.msdn.com/b/marcinon/) en un correo electrónico que me dice sobre el libro de Mark y el localizador de servicios. un antipatrón dijo: "No he leído el libro, así que no estoy familiarizado con el argumento de por qué es un patrón anti. ¿Podría aclarar por qué cree que es un mal diseño?" –

Para aclarar, envié un correo electrónico a Marcin, que sé que trabaja para Microsoft, y me sorprendió que nunca haya oído que el localizador de servicios ha sido llamado antipatrón (esto es fácil de encontrar en Internet). No estoy tratando de echarlo abajo. el autobús, pero es un ejemplo. Pienso en lo que Mark S. se refiere. –

dijiste: "Mira todos los ejemplos de ASP.NET MVC de inyección de dependencia publicados por mí o por el equipo ASP.NET MVC". ¿Puede proporcionar enlaces a algunos que sugiera? Tengo algunas referencias de servicio que usan muchos de mis controladores. Obtienen un objeto, que se proporciona a un objeto modelo (constructor o método) para hacer algún trabajo para formar un modelo (viewModel si se quiere) que se proporciona a una Vista. Mi razón principal para querer hacer IoC es de mi proyecto de prueba. Deseo poder proporcionar algo más que implemente IService desde ServiceReference sin llamar realmente al Servicio desde mi proyecto de prueba. – DaveH

¿Por qué MVC4 usa el Localizador de servicios antipatrón?

Respuesta

Cuestiones relacionadas