diferencias entre los contenedores de IoC

Question

Estoy buscando orientación sobre cómo elegir un contenedor de IoC para una aplicación ASP.NET MVC.

¿Cuáles son las diferencias entre (por ejemplo) StructureMap, Ninject, Castle Windsor, Unity, autofac y otros? ¿Alguien puede dar algunos consejos o enlaces a recursos que podrían ayudar a elegir una biblioteca?

Actualización : hay una pregunta ( Enterprise Library Unity vs Other IoC Containers ) que habla sobre las diferencias en la inicialización de los contenedores IoC.

Pero, ¿hay alguna diferencia en la funcionalidad que pueda hacer que algunos contenedores de IoC sean una mejor opción para una aplicación ASP.NET MVC?

Answer 1

Aquí hay un útil publicación de blog que compara características entre los diversos marcos de IOC disponibles en .Net, no sé si hay algo sobre MVC que favorezca un contenedor sobre otro.

Máx.

Answer 2

Una cosa que es diferente entre los diversos contenedores de IoC son los modos de ciclo de vida o instanciación que son compatibles de inmediato (cuándo crear una nueva instancia del componente):

• StructureMap
  • transitorio (llamado por solicitud), singleton, thread-local, per-HttpContext, per-HttpSession, Hybrid
• Ninject
  • transitorio, singleton, por subproceso, por HttpRequest
• Castillo Windsor
  • singleton, transitorio, por subproceso, agrupado, por solicitud Http (adicional disponible a través de las instalaciones)
• autofac
  • transitoria (fábrica), singleton, por HttpRequest
• Unidad
  • transitorio, singleton, por hilo

Answer 3

Personalmente me decidí por Autofac. Una cosa que parece ser realmente agradable es la disposición determinista de los recursos.

Eso y tenía integración ASP.Net con él también cuando lo revisé. Debería mirar otros marcos algún tiempo, pero no he tenido problemas con él. Los mensajes de error que te da cuando hay un componente irresoluble son realmente agradables.

Su mejor opción es probar proyectos con cada uno de ellos. Me he convertido en un verdadero fanático de hacer las configuraciones en código (tanto como sea posible) y usar configuraciones XML como copia de seguridad. Haga su propia lista de prioridades y pruébelas.

Answer 4

Personalmente, aquí es donde OOP deja de ser la solución correcta, porque no maneja IoC tan bien. Encontrar su propia solución puede ser mejor. Personalmente, paso el mío con F #, siempre que pueda controlar ambos extremos.

El nuevo Rx puede ayudar con algunos de estos problemas, pero aun así es solo tomar prestado un curita de la programación funcional.

Supongo que estamos atascados con los objetos como modelo básico para algunas cosas por un tiempo, sin embargo, afortunadamente en los servicios web los objetos funcionaron tan mal que los estándares ya se han alejado de ellos hacia interfaces funcionales como SOAP.