DI的五个W,IoC,因为它让我的大脑爆炸

Question

所以控制反转是一个模糊的描述,因此依赖注入成为新的定义.这是一个非常非常强大的解决方案,对于从未遇到过这种情况的人来说,可能同样令人困惑.

所以在我不想成为头灯的鹿的过程中,我读了一遍.我找到了几本很棒的书和在线帖子.但就像所有美好的事物一样,更多的问题出现而不是答案.

这个问题吸收了一个未知项目的变量,这些变量一旦被引入我的项目就会被实现.

解决方案:

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

我的注射器:

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
}

然后使用共享引用实现它作为Fed变量我创建了一个要实现的类,如:

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 Class将由另一个项目引用; 这将允许我随时随地实际调用这些属性:

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

这是实施,但我的问题是...... 我什么时候使用？

• 构造函数注入
• 二传手注射
• 接口注入

你什么时候使用其中一个？对于我提到的任务,我应该执行如此艰巨的任务来调整对其他项目所做的任何更改？

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

Answer 1

摘自Mark Seemann 的《.NET 中的依赖注入》第 4 章

\n\n

构造函数注入应该是 DI 的默认选择。它解决了类需要一个或多个依赖项的最常见场景。如果依赖类绝对可以在没有依赖关系的情况下运行\xe2\x80\x99t，那么保证是有价值的。

\n\n

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

\n\n

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

\n