Pregunta

Es raro que escuche a alguien usando el principio de Inversión de Control (Ioc) con .Net . Tengo algunos amigos que trabajan con Java que usan mucho más Ioc con Spring y PicoContainer.

Entiendo el principio de eliminar las dependencias de tu código ... pero tengo dudas de que es mucho mejor.

¿Por qué los programadores de .Net no usan (o usan menos) esos tipos de marcos? Si lo hace, ¿realmente encuentra un efecto positivo a largo plazo?

¿Fue útil?

Solución

Mucha gente usa IOC en .NET, y hay varios marcos disponibles para ayudar a usar IoC. Puede que lo veas menos en el lado de WinForms, porque es más difícil dejar que el contenedor lo conecte todo cuando estás diseñando formularios en Visual Studio, pero puedo decir que para las aplicaciones .NET del lado del servidor, donde al menos trabajo , IoC se utiliza con mucho éxito.

¿Por qué usarlo en .NET? Por la misma razón lo usas en cualquier otro lugar. Las 2 cosas más grandes que me gustan son:

  • El diseño para IoC tiende a imponer buenas prácticas de codificación: diseñar interfaces, bajo acoplamiento, alta cohesión. Esto también conduce a clases que son muy fáciles de probar por unidad.
  • La configuración del sistema a menudo se puede cambiar sin volver a compilar.

Algunas otras publicaciones que analizan los diferentes marcos de IoC / DI disponibles para .NET:

Otros consejos

Utilizo StructureMap para inyección de dependencia y solo recientemente comenzó a usarlo con iBATIS .NET para inyectar nuestros mapeadores de objetos de dominio en tiempo de ejecución (y no a través de un archivo de configuración XML, ¡no gracias!).

He visto beneficios inmediatos. Creamos interfaces para todos nuestros mapeadores (como IPersonMapper ) y luego agregamos Moq me permite escribir algunas pruebas unitarias bastante grandes sin bases de datos de forma rápida y sencilla.

Anteriormente (.NET 1.0) Escribí mi propio sistema de complementos principalmente para aprender sobre la reflexión. Desde entonces he implementado algún tipo de IoC en mis proyectos. Hace poco comencé a usar IoC para hacer pruebas unitarias mucho menos dolorosas de escribir. No me podía imaginar hacerlo de otra manera en este momento.

IoC no es realmente tan común en .Net hasta ahora. Y tiene todo que ver con Microsoft y las campañas de promoción que hicieron. Hasta ahora habían enfatizado más las capacidades de RAD de VS y mientras tanto se olvidaron de promover cosas como IoC y Di, pero ahora tienen su propio marco de trabajo llamado Unity y con el trabajo que hicieron en ASP.Net MVC.

Entonces, supongo que la mayoría de la gente comenzará a usar cosas así. Porque saben que tienen una alternativa de MS para usar.

Y yo uso StructureMap.

Se está volviendo más común. Mi proyecto actual usa Spring, y en mi proyecto anterior usamos Castle Windsor.

Ahora me gustaría usar la idea de 'convención sobre la configuración', para evitar todas esas declaraciones XML complejas.

Hay muchas teorías relacionadas con el uso de IoC .NET. Creo que hay una buena cantidad de desarrolladores que no tienen la experiencia en el área. No venían de un fondo de Java. Venían de un ASP clásico, y un fondo VB6. Además, Microsoft no promovió realmente el uso de IoC hasta hace poco.

Además, el uso de IoC supone varias cosas. Primero, debes entender para qué se usa y para qué estás obteniendo. En segundo lugar, debe desarrollar su código para que se pueda utilizar realmente un contenedor IoC.

IoC es más que solo usar otro elemento en la caja de herramientas. Se trata de saber usar, saber cuándo usarlo y madurar como desarrollador.

En lo que se refiere a .NET, tengo varios contenedores IoC. He usado Windsor, StructureMap, Unity y, más recientemente, Ninject. Sin embargo, tenga en cuenta que no los he usado todos en aplicaciones reales. Me gusta jugar y ver qué está pasando ahí afuera. Descubrí que el mercado para los contenedores IoC .NET es bastante bueno.

Lo uso para permitir que mis pruebas de unidad sustituyan a las clases simuladas (que simulan clases de producción reales) para objetos dependientes ascendentes, de modo que las pruebas de unidad solo ejecuten y prueben el código en la única clase. / p>

Prueba LinFu.IOC 2.0:

http://www.codeproject.com/KB/cs/LinFu_IOC.aspx

Es uno de los contenedores de IOC más flexibles que existen, y como Ninject, no hay ningún archivo XML que mantener. Sin embargo, a diferencia de Ninject, LinFu no lo obliga a escribir ningún código de enlace para conectar sus dependencias. ¡Echar un vistazo! :)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top