c# - ioc - Inversión del control con.net
unity ioc (7)
Es raro que escuche a alguien usando el principio de Inversion of 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 dependencias de su código ... pero tengo una duda 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?
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 provienen de un fondo Java. Vinieron de un ASP clásico y un fondo VB6. Además, Microsoft realmente no promovió el uso de IoC hasta hace poco.
Además, usar IoC supone varias cosas. En primer lugar, debe comprender para qué se utiliza y qué se obtiene con ello. En segundo lugar, debe desarrollar su código para que se pueda usar realmente un contenedor IoC.
IoC es más que solo usar otro elemento en la caja de herramientas. Se trata de saber cómo usar, saber cuándo usarlo y cómo 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 allí afuera. Descubrí que el mercado de contenedores IOC .NET es bastante bueno.
IoC no es tan común en .Net hasta ahora. Y tiene todo que ver con Microsoft y sus campañas de promoción. hasta ahora estaban enfatizando más las capacidades de RAD de VS y mientras tanto olvidaron promover cosas como IoC y Di pero ahora tienen su propio marco llamado Unity y con el trabajo que hicieron en ASP.Net MVC.
Así que supongo que la mayoría de la gente comenzará a usar cosas como esa. Porque saben que tienen una alternativa de MS para usar.
Y uso StructureMap.
Lo uso para permitir que mis pruebas unitarias sustituyan las clases simuladas (simulando clases de producción reales) por objetos dependientes en sentido ascendente, de modo que las pruebas de mi unidad realmente solo ejecuten y prueben el código en el método de clase única para el que están escritas.
Se está volviendo más común. Mi proyecto actual usa Spring, y en mi proyecto anterior usamos Castle Windsor.
Ahora me gustaría utilizar la idea de ''convención sobre configuración'' para evitar todas esas declaraciones XML complejas.
Utilizo StructureMap para la inyección de dependencias y recientemente comencé 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. Crear interfaces para todos nuestros mapeadores (como IPersonMapper ) y luego agregar Moq me permite escribir algunas pruebas de unidades sin bases de datos muy buenas de forma rápida y fácil.
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. Recientemente empecé a usar IoC para hacer que las pruebas unitarias sean menos dolorosas de escribir. No podría imaginar hacerlo de otra manera en este punto.
Pruebe LinFu.IOC 2.0:
http://www.codeproject.com/KB/cs/LinFu_IOC.aspx
Es uno de los contenedores IOC más flexibles que existen, y al igual que Ninject, no hay un archivo XML que mantener. Sin embargo, a diferencia de Ninject, LinFu no lo obliga a escribir ningún código vinculante para unir sus dependencias. ¡Echar un vistazo! :)
Mucha gente usa COI en .NET, y hay varios marcos disponibles para ayudar con el uso de IoC. Puede que lo veas menos en WinForms, porque es más difícil dejar que el contenedor conecte todos los elementos cuando estás diseñando formularios en Visual Studio, pero puedo decir que para las aplicaciones .NET del lado del servidor, donde trabajo al menos , IoC se usa con mucho éxito.
¿Por qué usarlo en .NET? Por el mismo motivo, lo usas en todos lados. Las 2 cosas más importantes que me gustan son:
- Diseñar para IoC tiende a imponer buenas prácticas de codificación: diseñando interfaces, bajo acoplamiento, alta cohesión. Esto también conduce a clases que son muy fáciles de probar en una unidad.
- La configuración del sistema a menudo se puede cambiar sin volver a compilar.
Algunos otros comentarios sobre los diferentes frameworks de IoC / DI disponibles para .NET: