依赖注入 – 为什么我需要一个IoC容器而不是直接的DI代码？

我一直在使用 Dependency Injection(DI)一段时间，注入在构造函数，属性或方法。我从来没有觉得需要使用 Inversion of Control(IoC)容器。然而，我读的越多，我感觉从社区使用IoC容器的压力越大。

我使用.NET容器，如StructureMap，NInject，Unity和Funq.我仍然没有看到IoC容器如何将有益/改进我的代码。

我也害怕开始使用一个容器在工作，因为我的许多同事都会看到他们不明白的代码。他们中的许多人可能不愿意学习新技术。

请说服我，我需要使用IoC容器。当我和我的同事们在工作时，我将使用这些参数。

哇，不能相信乔尔会喜欢这个：

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

在这：

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

许多人没有意识到你的依赖链可以嵌套，并且很快变得难以手动连接它们。即使有工厂，你的代码的重复是不值得的。

IoC容器可能很复杂，是的。但对于这个简单的案例，我已经表明它是令人难以置信的容易。

好吧，让我们更好地证明这一点。假设您有一些要绑定到智能UI的实体或模型对象。这个智能UI(我们称之为Shindows Morms)希望您实现INotifyPropertyChanged，以便它可以做更改跟踪&相应地更新UI。

“好吧，那听起来不那么难”，所以你开始写作。

您首先是：

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

..结束了这个：

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;
}

这是令人厌恶的管道代码，我认为，如果你编写代码像手工，你是从你的客户端偷。有更好，更聪明的工作方式。

听说这个词，工作更聪明，不难？

好吧，你的团队里有一个聪明的人来了，说：“这里有一个更容易的方式”

如果你让你的属性虚拟(冷静下来，这不是一个大交易)，那么我们可以自动编织属性行为。 (这称为AOP，但不要担心的名字，专注于它会为你做什么)

根据您使用的IoC工具，您可以执行如下所示的操作：

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

Poof！所有的手动INotifyPropertyChanged BS现在自动生成的，对于有问题的对象的每个虚拟属性设置。

这是魔法吗？是！如果你可以相信这个代码执行它的工作，那么你可以安全地跳过所有的属性包装mumbo-jumbo。您有业务问题要解决。

一些其他有趣的使用IoC工具做AOP：

> Declarative&嵌套数据库事务> Declarative&嵌套工作单元>日志>前/后条件(按合同设计)

依赖注入 – 为什么我需要一个IoC容器而不是直接的DI代码？

猜你在找的设计模式相关文章