12

我有一个类，它有一个这样的构造函数：

    private string _someString;
    private ObjectA _objectA;
    private ObjectB _objectB;
    private Dictionary<Enum, long?> _dictionaryA;
    private Dictionary<Tuple<Enum,long?>, long?> _dictionaryB; 

    public SomeDiClass(string someString)
    {
        _someString = someString;

        _objectA = new ObjectA();
        _objectB = new ObjectB();

        _dictionaryA = new Dictionary<Enum, long?>();
        _dictionaryB = new Dictionary<Tuple<Enum, long?>, long?>();
    }

我想从此构造函数中创建依赖项。在第一步中，我会将 ObjectA 和 B 依赖项移动到构造函数参数中，以通过构造函数注入来注入它们。我想为此目的使用 IoC 容器，这就是我目前停留的地方。问题是如何处理 someString 和字典。我需要将它们注入课堂，因为字典的内容将是单元测试的重要组成部分。通过属性注入注入字符串和字典是否是一个好主意（我在其他类中不需要它们），所以我最终会得到这样的东西？：

    private ObjectA _objectA;
    private ObjectB _objectB;

    public string SomeString { get; set; }
    public Dictionary<Enum, long?> DictionaryA { get; set; }
    public Dictionary<Tuple<Enum, long?>, long?> DictionaryB { get; set; }

    public SomeDiClass(ObjectA objectA, ObjectB objectB)
    {
        _objectA = objectA;
        _objectB = objectB;
    }

是否有解决此类问题的最佳实践？

4

2 回答 2

28

依赖注入不是最终目标，而是对一组特定问题的解决方案。例如，依赖注入使得替换单元测试的抽象变得容易，并使您的应用程序更加灵活，因为您可以交换、装饰和拦截依赖项，而无需更改使用类。依赖注入原理、实践和模式(DIPP&P)一书免费提供的第 1 章对依赖注入进行了很好的介绍。

这并不意味着您应该注入一个类所具有的每个依赖项，因为它必须帮助您使类更可测试并且系统更易于维护。因此，您必须问自己，从测试的角度来看，从外部注入这些字典是否有帮助，或者是否有助于使您的应用程序更加灵活。要很好地掌握要注入的内容和不注入的内容，您应该了解易失性和稳定依赖关系的概念，可以在DIPP&P 第 1 章的第 1.3 节中阅读。

无论从测试还是可维护性的角度来看，这都是一个很难回答的问题，因为您的问题没有足够的细节。但这里有一些提示：

您通常想要注入到类中的唯一东西是服务和配置值。

  • 服务是一些提供“服务”的合同/抽象/接口。这通常意味着该服务将代表您执行某些操作，例如计算价格、与数据库通信、缓存值、返回系统时间或格式化您的硬盘驱动器 :)

  • 配置值就是它的样子；只是一个值。但是你需要注入它——它不能被硬编码到类中，并且你不希望类从 中获取值本身ConfigurationManager，因为这会创建一个隐藏的依赖项（在 上Configurationmanager）并且这个会使课程更难测试。

其他东西，例如原语、消息、DTO、集合类型和实体，以及任何其他不提供任何服务（业务逻辑）并且不妨碍单元测试的东西，都不必抽象，并且，因此，不必注入（实际上不应该通过构造函数或属性注入）。在您的情况下，字典是类内部状态的一部分SomeDiClass，而不是您的类所依赖的服务。

另一方面，如果这些字典被其他服务重用，则必须注入这些字典。但是你永远不想直接注入这样的字典本身，因为字典本身不是服务。相反，您需要围绕它们创建一个抽象；隐藏该字典的详细信息并为应用程序提供围绕它的服务的东西。

于 2013-09-13T07:19:18.310 回答
5

当您的类型的对象创建超出您的控制范围时，您应该使用属性注入（或 setter 注入）。像 aspx Page、HttpHandler、ApiController 等。对于所有其他情况，建议使用构造函数注入。

要使用 StructureMap 解决 aspx 页面的依赖关系，我使用以下方法。

首先，我创建一个 BasePage 类并在构造函数中使用 StructureMap 的 BuildUp() 方法来解决派生页面的依赖关系。代码如下：

public class BasePage : Page
{
    public BasePage()
    {
        // instruct StructureMap to resolve dependencies
        ObjectFactory.BuildUp(this);
    }
}

public class Default : BasePage
{
     public ICustomerService customerService { get; set; }

     protected void Page_Load(object sender, EventArgs e)
     {
         // can start using customerService
     }
}

public class Login : BasePage
{
     public IAuthenticationService authenticationService { get; set; }

     protected void Page_Load(object sender, EventArgs e)
     {
         // can start using authenticationService
     }
}
于 2013-10-06T23:29:06.623 回答