.NET Framework类的Unity最佳实践

Question

我刚刚开始使用任何DI / IoC工具集，并且有一个非常基本的问题。我正在使用Unity，因为我们还将在整个应用程序中使用许多Enterprise Library块。

我遇到的问题是围绕.NET框架类的依赖关系。例如，在我目前正在处理的一个类中，我需要创建DirectoryInfo类。根据我的理解，DI中的最佳实践之一是永远不要使用“new”关键字 - 因为这引入了一种硬依赖关系。那我该如何获得一个新的DirectoryInfo？将它作为项添加到容器中，并使容器成为类的依赖项？这似乎在现实生活中使用是不切实际的，因为我最终会将容器配置成数以千计的框架类。我认为这是一场维护噩梦。

Answer 1

我想说这有点过于工程化了。我认为应该传入要创建的DirectoryInfo的路径，或者传递某种类型的配置存储库（或服务）类，它保存（或提供一种获取方式）数据。

Answer 2

我不会在容器中注册像DirectoryInfo这样的低级别类 - 在应用程序的某些地方使用new不是一个问题，只要这个要求不会“泄漏”到更高级别的类中。所以在这个例子中，直接在一个类中创建和使用DirectoryInfo可能是有意义的，但是该类的实例是由容器注入它们的依赖项。

Answer 3

首先，您可以看作SystemWrapper库。它包装了DirectoryInfo对象，因此您可以对其进行模拟。

接下来，您可以查看tutorial to TDD using Rhino Mocks and SystemWrapper。你可以看到DI的用法;但是，那里的例子没有使用任何IoC。

希望它有所帮助。

Answer 4

我看到它的方式，BCL（基类库）中的大多数类都是utiity类，并且除了直接调用图之外通常没有大量其他依赖项。

DI旨在压缩调用图并防止类之间的大量串扰。因此，以及你无法对BCL的烦恼做任何事情的事实，你也可以接受它们的本身，继续使用新的......

您不想要的唯一原因是出于测试目的。你通常不会测试BCL类，但是你可能想用一个模拟版本替换一个BCL类，这样它实际上不会做任何类的操作，只是假装这样做..你可以使用像SystemWrapper在必要时执行此操作。