¿Qué debo considerar al elegir un marco de inyección de dependencias para .NET

Question

ver también Which C#/.NET Dependency Injection frameworks are worth looking into?

Ahora hay muchas dependencyinjection marcos para elegir. A menudo solía verse obligado a utilizar un marco de inyección de dependencia determinado debido a una biblioteca que estaba utilizando. Sin embargo, el Common Service Locator library ha permitido que el código de la biblioteca sea independiente de los marcos de inyección.

El tiempo que toma aprenderlos a todos lo suficiente como para decidir cuál usar no es razonable. No creo que hayamos llegado a una etapa en la que podamos hablar sobre el mejor marco de inyección de dependencias. Entonces, ¿qué preguntas debería hacer sobre el proyecto y sobre mí mismo para ayudar a decidir cuál es el mejor marco de inyección de dependencia para usar en un caso determinado?

También sería útil saber por qué elige el marco de inyección de dependencia que está utilizando actualmente y si todavía está contento con eso.

¿Todavía hay un vocabulario útil para usar al comparar los estilos de marcos de inyección de dependencia?

¿Funciona la biblioteca de Localizador de servicios en la vida real, o tiene la habilidad de utilizar muchos marcos de inyección de dependencia diferentes en el mismo proyecto?

¿Cuán fácil es refractar su código con cada Marco de inyección de dependencia, por ejemplo, herramientas como ReSharper funcionan bien con un marco determinado?

Answer 1

FYI, esta misma mañana me encontré con una interesante comparación entre todos los contenedores IoC .NET aquí:

http://elegantcode.com/2009/01/07/ioc-libraries-compared/

Un puñado de preguntas:

1. ¿Cuánto soporte estándar hacer ¿necesitas? La primavera es probablemente la más grande que existe. Todos lo han usado o ya lo han escuchado, así que mucha información. También es probable que tenga la mayor cantidad de características, pero eso significa que hay mucho más por aprender. Un contenedor más pequeño como Autofac podría ser agradable, pero es posible que te encuentres con un problema en el que no encontrarás ayuda.
2. ¿Está a mano con la configuración Xml? Cada contenedor de IoC depende de la configuración y configuración de algún tipo. Spring y Unity son Xml pesados.
3. ¿Es esta una elección permanente? Si se encuentra en uno de esos lugares donde solo tiene una oportunidad, no importará. Pero, si alguna vez quiere elegir otra solución en el futuro, probablemente no desee un IoC que requiera que usted atribuya sus clases (por lo tanto, el inverso de la pregunta anterior) porque se odiará a sí mismo cuando tenga que romper todo esas cosas afuera. En comparación, la eliminación de algunas configuraciones xml podría no ser tan dolorosa.
4. ¿Cómo es su tienda? Tuve problemas para lanzar un par de opciones de código abierto solo por el "jadeo! ¡No es Microsoft!" reacciones. Si eres una tienda directa de MS, usar Unity será una victoria cultural mucho más fácil.

En una nota personal:

he utilizado StructureMap por las mismas razones mencionadas en el blog he vinculado.Creo que Xml config es un gran problema para mantener y, sobre todo, depurar (ver WCF). Todavía no he probado Ninject, pero en función de su comercialización, ¡debe ser superradio!

Answer 2

Creo que la elección se reduce a encontrar un marco que cumpla con sus requisitos y luego con sus preferencias personales.

¿Su proyecto ya utiliza una biblioteca como rinoceronte que ya se integra con un marco DI? Si lo hace, podría ser un buen punto de partida si quiere evitar el uso de "muchos marcos de inyección de dependencias diferentes".

Salida estas dos puestos:

• SO: Enterprise Library Unity vs Other IoC Containers
• SO: Which .NET dependency injection framework do you use?

Answer 3

primavera y la unidad son XML pesada.

No estoy de acuerdo con esa afirmación para Unity; puede escribir

container.RegisterType<IRobot, MrRoboto>(); 

y realizar su configuración en código utilizando una interfaz de estilo fluido. Personalmente me gusta la Unidad.

Answer 4

Es difícil responder a qué marco es 'mejor', pero se puede decir qué marco es el más fácil: el inyector simple:

El inyector simple es una inversión de fácil uso de la biblioteca de Control para .NET y Silverlight. Es el único compatible con la configuración basada en código y es un punto de partida ideal para los desarrolladores no están familiarizados con las bibliotecas más grandes IOC/ DI

http://simpleinjector.codeplex.com/

Enchufe desvergonzado por cierto ;-)