IoC y ASP.NET MVC, ¿dónde comienza todo?

Question

Veo "IoC" y "DI" mencionados en casi todos lados para ASP.NET MVC. Aunque soy muy consciente de ... 'qué tipo de' estos son, es uno de esos conceptos flotantes casi ambiguos y amorfos que parece haber pasado por alto, o simplemente no estoy mirando en el lugar correcto. Con el próximo lanzamiento de ASP.NET MVC 3.0, lo estoy viendo aún más. Tanto que parece que es una parte entera de la programación, simplemente no sé.

He intentado buscar libros sobre los temas, pero la mayoría de lo que encuentro parece hacer muchas suposiciones (historia en Ruby, entender qué es pero no cómo usarla, etc.).

Estoy preguntando por adelantado y claro. ¿Qué es IoC, y por qué me importa? ¿Hay sitios web decentes que cubran esto desde una perspectiva de programador principiante? Supongamos que no sé nada al respecto. Supongamos que no sé nada más que C#. Leí cada libro, blog y tutorial en C# de .NET 1.1 a .NET 2.0, y cuando tocan .NET 3.5 y LINQ, se volvió tan difícil de manejar que no pude mantener el ritmo. Soy un desarrollador novato que trabaja en ASP.NET MVC/C# y no puedo evitar sentir que me estoy perdiendo algo muy importante. (Estoy teniendo los mismos sentimientos sobre DI (inyección de dependencia))

He buscado en Google, he leído blogs, he visto Castle.Windsor, he visto código de ejemplo, he navegado libros y webcasts, y todavía estoy tan a oscuras. Se siente como una de esas historias internas en el trabajo que sabes que debes conocer, pero por alguna razón, no, y la escuela realmente no me preparó para eso.

StackOverflow siempre ha demostrado ser lo mejor de lo mejor en la comunidad de desarrollo para mí. A través de la universidad y el trabajo introductorio, y el trabajo independiente de bajo nivel, he amalgamado mi educación en programación de otros programadores (aunque, como yo lo entiendo, eso no es necesariamente algo de lo que avergonzarse). Entonces, una vez más, simplemente le digo a la comunidad.

¿Huh? No entiendo.

Hablando con muchos de mis colegas que intentan entrar en el mismo campo, muchos de ellos piensan lo mismo. Así que no puedo evitar sentirme en algún momento, los programadores "novatos" nos perdimos la nota de estos enfoques conceptuales de la codificación. Me gustaría no solo obtener esta pregunta, pero creo que un buen hilo para otras personas como yo que estamos tratando de entenderlo podría ser una idea inteligente (y si existe, debe hacerse más obvia)

Algo de lo que he encontrado que ha sido muy útil y ha sido http://www.theserverside.com/news/1321158/A-beginners-guide-to-Dependency-Injectionhttp://www.dotnetspark.com/kb/1222-inversion-control--beginner-guide.aspx

Pero todavía me quedo rascándome la cabeza en una serie de cuestiones de por qué esto es importante. A decir verdad, siento que una gran parte de la comunidad de desarrolladores se siente de esta manera tanto con IoC como con Unit Testing. Muy poco establece qué es y los ejemplos descubiertos son generalmente muy pobres o muy difíciles de entender. Cuando se introdujo .NET, fue independiente. No necesitaba muchos otros conceptos para ejecutar programas simples. Ahora, .NET es un lenguaje respetado, y todo bajo el sol lo está adoptando (nHibernate, MVC, MVP, MVVP, plataformas Clouding, arquitectura de juegos, etc.)

(Por favor, siéntase libre de señalar si solo soy flagrantemente mal. No me llamo a mí mismo "bueno" de ninguna manera. Pero sé C#, y lo sé muy bien.Me considero un aprendiz muy rápido y en un momento tan difícil como el que tengo con esto, solo tengo que suponer que hay algún 'agujero' que necesita ser llenado)

Answer 1

Dejemos todos los marcos de la IoC a un lado y analicemos el concepto. IoC no es un concepto nuevo y ha existido por mucho tiempo. IoC básicamente se implementa para hacer que su sistema se acople de forma suelta a cierto subsistema. Logramos el desacoplamiento al extraer el comportamiento común/núcleo del subsistema en un contrato. El contrato suele ser en forma de interfaz. Ahora dependes de esta interfaz. No está preocupado acerca de cómo un sistema en particular le da el comportamiento que busca.

Recientemente tuve un encuentro de la vida real con esto. Estamos teniendo un sistema de pago existente y luego estamos desarrollando un nuevo sistema de pago para cumplir con PCI. Lo que hace en este tipo de situación es que extrae las características comunes de ambos sistemas en una interfaz y luego su aplicación interactúa con estos dos sistemas solo a través de la interfaz. Puede usar un indicador en el archivo de configuración o el patrón de fábrica o, en última instancia, un marco de IoC para inyectar esta dependencia en su aplicación. En tiempo de ejecución, su aplicación obtendrá el objeto del que depende. Necesita DI/IoC en un entorno donde existe incertidumbre con respecto al uso de cualquier subsistema dado por cualquier motivo. En este ejemplo, el nuevo sistema de pago no pudo entregarse a tiempo y, por lo tanto, mi aplicación necesitaba una opción configurable para alternar entre cualquier sistema en tiempo de ejecución. Si no hago IoC, tendré que hacer un cambio de código cada vez que las empresas cambien de opinión.

Otra necesidad de IoC es hacer TDD. Lo mismo que describí anteriormente se puede usar para desarrollar una implementación simulada de aplicaciones reales y se puede usar para realizar pruebas mientras el componente real aún está en desarrollo.

Dependency Injection es un buen libro para comenzar. También puede descargar un documento gratuito sobre DI del mismo autor here.

Actualización: Adición de código para una mayor claridad

public interface ITest 
    { 
     void Hello(); 
    } 

Ahora puedo tener dos diferentes implementaciones concretas:

public class Hi : ITest 
    { 
     public void Hello() 
     { 
      HttpContext.Current.Response.Write("Hi there!"); 
     } 
    } 

    public class HelloMessage : ITest 
    { 
     public void Hello() 
     { 
      HttpContext.Current.Response.Write("Hello there!"); 
     } 
    } 


ITest messenger; 

if (User Needs "Hi") 
{ 
    messenger = new Hi(); 
} 
else if (User Needs "Hello") 
{ 
    messenger = new HelloMessage(); 
} 

messenger.Hello(); 

Todo mi solicitud tiene que hacer es llamar al método disponible en el contrato. En este momento, la aplicación maneja las dependencias de forma explícita, pero está libre de cualquier implementación concreta. Sin embargo, todavía está ligado a estas dos implementaciones concretas. Los marcos de IoC nos ayudan a externalizar este trabajo a un archivo de configuración. Allí puedo proporcionar cualquier otra implementación concreta independientemente de cómo se implemente y la aplicación continuará funcionando sin ningún cambio de código.

A continuación se muestra el código en el que utilizo Unity 2 y la externalización del manejo explícito de las dependencias por mi cuenta.

using (IUnityContainer container = new UnityContainer()) 
      { 
       container.LoadConfiguration(); 

       ITest messenger = container.Resolve<ITest>(); 

       messenger.Hello(); 
      } 

Config para el mismo:

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity"> 
    <assembly name="Injection"/> 
    <container> 
    <register type="Injection.ITest" mapTo="Injection.Hi"/> 
    </container> 
</unity> 

HTH

Answer 2

Para algunas intros de video, echa un vistazo a DimeCasts.net .

Las dos principales razones que me gusta Ioc:

1. más fácil de pruebas unitarias.
2. Más fácil de intercambiar datos de back-end para probar. Digamos que tiene un IPersonRepository. Su código implementa un PersonRepository que carga datos de la base de datos. Pero, ¿qué pasa si no tiene ningún dato en la base de datos o la base de datos aún no está configurada? Utiliza IoC para implementar un DummyPersonRepository que cargará los datos desde otro lugar, como un archivo XML o datos codificados.

Answer 3

me preguntó algo similar hace un tiempo, algunas respuestas buenas de allí en Examples of IoC Containers

Answer 4

Mira el vídeo libre "Dependencia Inyección e inversión de control "en http://tekpub.com/channels/free

Answer 5

Creo que empezará a comprender las cosas de IoC/DI cuando comprenda por qué y cuándo se usa. No me preocuparía demasiado sobre qué contenedor de IoC usar. En esencia, podrías escribir un contenedor básico (en el nivel más básico, es solo un diccionario que mapea una interfaz para una implementación concreta). Here es un buen video que muestra cómo se haría eso.

El concepto central es que fomenta el acoplamiento libre de componentes, lo que significa que el código es más fácil de probar y no depende de otras clases concretas.

This link tiene detalles sobre los principios SÓLIDOS, su pregunta se refiere particularmente al "D" (principio de inversión de dependencia), pero los otros también serán de interés.