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

前端之家收集整理的这篇文章主要介绍了依赖注入 – 为什么我需要一个IoC容器而不是直接的DI代码?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在使用 Dependency Injection(DI)一段时间,注入在构造函数属性方法。我从来没有觉得需要使用 Inversion of Control(IoC)容器。然而,我读的越多,我感觉从社区使用IoC容器的压力越大。

我使用.NET容器,如StructureMapNInjectUnityFunq.我仍然没有看到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&嵌套工作单元>日志>前/后条件(按合同设计)

原文链接:https://www.f2er.com/javaschema/283318.html

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