使用DI框架时，新服务如何知道其他服务可用？

Question

在一个使用DI框架的大型项目中（例如Ninject），在实现一个新的“服务”以找出可用作依赖关系的其他“服务”时，存在哪些选项。在使用DI之前，我注意到在我们的代码库中有一种倾向，即获得对可以访问所有可用功能的“上帝”对象的引用，然后Visual Studio的智能感知对于发现所有可用功能变得非常有用（显然这是方法是唯一可能的，因为首先有这样一个对象的建筑决策很差）。

我所能一些可能的答案，有兴趣什么为他人工作：

1. 你应该知道你正在工作的不够好， 知道其他类/存在服务（例如整个系统，如果我有 静态类，我只需要知道他们存在能够 使用它们）。
2. 您保持良好的 代码库的外部文档，以便所有的开发人员都能理解所有的类/服务 （这给我带来了很大的文档负担）。
3. 创建一个API来查询DI容器（Ninject内核）中所有绑定的列表 ，以查看哪些服务可用（可能只有 单身人士）。这也可以作为构建系统的一部分完成， 在开发者 可以参考的每个构建上自动生成文档。

这对于其他开发者来说有没有问题？

Answer 1

通常情况下，您不希望看到系统中存在的所有服务，然后选择其中一个服务。你想要访问一个功能所有权。以某种方式用名称空间来组织您的类，以便在哪里寻找它。

E.g.如果我想知道.NET中可用的集合，我输入System.Collections.Generic.，智能感知给我一个选项列表。

Answer 2

我倾向于组织我的代码库，以便我有一个中心的“接口”项目，所有其他项目都有参考。然后我的Logger只能通过​​接口使用，并且日志模块可以选择提供哪个具体的​​。你不应该要求具体的课程 - 这打破了DI的目的。

一般而言，当您正在实施新服务时，您应该已知道您需要的依赖关系。如果你不知道你应该使用什么，问谁做。这相当于有足够的文档 - 依靠智能感知会给你一个非常浅的想法，你应该把它当作依赖。相反，您应该咨询文件或了解该地区的人员。