¿Por qué necesito un contenedor IoC en lugar de un código DI sencillo? [cerrado]

Vaya, no puedo creer que Joel estuviera a favor de esto:

var svc = new ShippingService(new ProductLocator(), 
   new PricingService(), new InventoryService(), 
   new TrackingRepository(new ConfigProvider()), 
   new Logger(new EmailLogger(new ConfigProvider())));

Más allá de esto:

var svc = IoC.Resolve<IShippingService>();

Mucha gente no se da cuenta de que su cadena de dependencias puede anidarse y rápidamente resulta difícil de manejar conectarlas manualmente. Incluso con las fábricas, la duplicación de su código simplemente no vale la pena.

Los contenedores de COI pueden ser complejos, sí. Pero en este sencillo caso que he demostrado, es increíblemente fácil.

Bien, justifiquemos esto aún más. Supongamos que tiene algunas entidades u objetos de modelo que desea vincular a una interfaz de usuario inteligente. Esta interfaz de usuario inteligente (la llamaremos Shindows Morms) quiere que implemente INotifyPropertyChanged para que pueda realizar un seguimiento de cambios y actualizar la interfaz de usuario en consecuencia.

"Está bien, eso no suena tan difícil", así que empiezas a escribir.

Empiezas con esto:

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime CustomerSince { get; set; }
    public string Status { get; set; }
}

..y terminar con esto :

public class UglyCustomer : INotifyPropertyChanged
{
    private string _firstName;
    public string FirstName
    {
        get { return _firstName; }
        set
        {
            string oldValue = _firstName;
            _firstName = value;
            if(oldValue != value)
                OnPropertyChanged("FirstName");
        }
    }

    private string _lastName;
    public string LastName
    {
        get { return _lastName; }
        set
        {
            string oldValue = _lastName;
            _lastName = value;
            if(oldValue != value)
                OnPropertyChanged("LastName");
        }
    }

    private DateTime _customerSince;
    public DateTime CustomerSince
    {
        get { return _customerSince; }
        set
        {
            DateTime oldValue = _customerSince;
            _customerSince = value;
            if(oldValue != value)
                OnPropertyChanged("CustomerSince");
        }
    }

    private string _status;
    public string Status
    {
        get { return _status; }
        set
        {
            string oldValue = _status;
            _status = value;
            if(oldValue != value)
                OnPropertyChanged("Status");
        }
    }

    protected virtual void OnPropertyChanged(string property)
    {
        var propertyChanged = PropertyChanged;

        if(propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(property));
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

Ese es un código de plomería repugnante, y sostengo que si escribes un código como ese a mano, le estás robando a tu cliente . Hay formas de trabajar mejores y más inteligentes.

¿Alguna vez escuchó ese término, trabajar más inteligentemente, no más duro?

Bueno, imagina que un tipo inteligente de tu equipo se acerca y dice: "Aquí tienes una manera más fácil".

Si hace que sus propiedades sean virtuales (cálmese, no es gran cosa), entonces podemos incorporar ese comportamiento de propiedad automáticamente. (Esto se llama AOP, pero no te preocupes por el nombre, concéntrate en lo que hará por ti)

Dependiendo de la herramienta de IoC que esté utilizando, podría hacer algo parecido a esto:

var bindingFriendlyInstance = IoC.Resolve<Customer>(new NotifyPropertyChangedWrapper());

¡Maricón! Todo ese INotifyPropertyChanged BS manual ahora se genera automáticamente para usted, en cada definidor de propiedad virtual del objeto en cuestión.

¿Es esto magia? SÍ ! Si puede confiar en el hecho de que este código hace su trabajo, entonces puede omitir con seguridad todas esas propiedades que envuelven palabrerías. Tienes problemas comerciales que resolver.

Algunos otros usos interesantes de una herramienta IoC para realizar AOP:

• Transacciones de bases de datos declarativas y anidadas
• Unidad de trabajo declarativa y anidada
• Inicio sesión
• Condiciones Pre/Post (Diseño por Contrato)

Oct 07 '2009 15:10 Ben Scheirman