c# - DI、IoC 的五个 W，因为它让我的大脑爆炸

Question

所以控制反转是一个模糊的描述，所以依赖注入(inject)成为了新的定义。这是一个非常非常强大的解决方案，对于从未遇到过它的人来说很可能会感到困惑。

因此，为了不成为车头灯下的鹿，我开始阅读。我发现了几本很棒的书和在线帖子。但就像所有美妙的事情一样，更多的问题出现了，而不是答案。

问题是，从一个未知的项目中吸收变量，一旦将它们引入我的项目中就会实现。

解决方法:

public interface ISiteParameter
{
    Guid CustomerId { get; set; }
    string FirstName { get; set; }
    string LastName { get; set; }
    string Phone { get; set; }
}

我的注入(inject)器:

public interface IInjectSiteParameter
{
     void InjectSite(ISiteParameter dependant);
}

然后我创建了这个:

public class SiteContent : IInjectSiteParameter
{
    private ISiteParameter _dependent;

    #region Interface Member:
    public void InjectSite(ISiteParameter dependant)
    {
        _dependant = dependant;
    }
    #endregion
}

然后用一个共享引用来实现它我创建了一个要实现的类，如下所示:

public class SiteParameters : ISiteParameter
{    
   public Guid Customer Id { get; set; }
   public string FirstName { get; set; }
   public string LastName  { get; set; }
   public string Phone { get; set; }
}

现在 SiteParameters 类 将被其他项目引用；这将使我能够随时随地调用这些属性:

ISiteParameter i = new ISiteParameter();
MessageBox.Show(i.Guid + i.FirstName + i.LastName + i.Phone);

那是实现，但我的问题是……我什么时候使用？

• 构造函数注入(inject)
• 二传手注入(inject)
• 接口(interface)注入(inject)

您什么时候会使用其中一个？对于我提到的任务，我是否应该实现如此困难的任务来调整对其他项目所做的任何更改？

我的思维过程是否偏离了曲线？

Answer 1

摘自 Dependency Injection in .NET 的第 4 章通过马克·西曼

构造函数注入(inject)应该是 DI 的默认选择。它解决了一个类需要一个或多个依赖项的最常见场景。如果依赖类在没有依赖的情况下绝对无法运行，那么保证是有值(value)的。

只有当您正在开发的类具有良好的本地默认值并且您仍然希望使调用者能够提供该类依赖项的不同实现时，才应使用属性注入(inject)。属性注入(inject)也可用于框架要求您具有默认构造函数的情况，例如 ASP.NET 页面。

当依赖性随每个方法调用而变化时，最好使用方法注入(inject)。当依赖项本身表示一个值时可能会出现这种情况，但当调用者希望向消费者提供有关调用操作的上下文的信息时，这种情况经常出现。