2008-10-30 12 views
6

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

Entiendo el principio de eliminar dependencias de su código ... pero tengo una duda de que es mucho mejor.

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

+0

Solo Google "Alt.net" - encontrará mucha gente usando IOC en .net. Microsoft incluso tiene sus propios marcos de IOC, como Unity. –

Respuesta

6

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 grandes que me gustan son:

  • Proyectos de la COI tiende a establecer buenas prácticas de codificación - el diseño de 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 mensajes que discuten los diferentes marcos IOC/DI para .NET:

4

que utilizo StructureMap para la inyección de dependencia y sólo recientemente han comenzado a usar con iBATIS.NET para inyectar nuestros mapeadores de objetos de dominio en tiempo de ejecución (y no t 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 de una manera fácil y rápida.

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.

2

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.

1

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.

1

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, el uso de 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 simplemente 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.

0

Lo uso para permitir que mis pruebas unitarias sustituyan las clases simuladas (simulando clases de producción reales) por objetos dependientes en sentido ascendente para que mis pruebas unitarias solo ejecuten y prueben el código en el método de una clase para el que se escriben.

0

Trate LinFu.IOC 2.0:

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

Es uno de los contenedores COI más flexibles por ahí, y al igual que Ninject, no hay archivo XML de 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! :)

Cuestiones relacionadas