0

在使用 DI 框架（例如我的例子中的 Ninject）的大型项目中，在实现新的“服务”以找出哪些其他“服务”可用作依赖项时存在哪些选项。在使用 DI 之前，我注意到我们的代码库中倾向于获取对“上帝”对象的引用，该对象几乎可以访问所有可用功能，然后 Visual Studio 的 IntelliSense 将变得非常有助于发现所有可用功能（显然这方法之所以可行，是因为最初拥有这样一个对象的架构决策不佳）。

我可以提供一些可能的答案，并对对其他人有用的东西感兴趣：

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

这曾经是其他开发人员的问题吗？

4

2 回答 2

1

通常您不希望看到系统中存在所有服务，然后选择其中一个。你想访问一个功能。以某种方式使用名称空间来构造您的类，以便在哪里查找它是显而易见的。

例如，如果我想知道 .NET 中有哪些可用的集合，我键入System.Collections.Generic.，IntelliSense 会给我一个选项列表。

于 2013-02-13T18:16:20.160 回答
0

我倾向于组织我的代码库，以便我有一个所有其他项目都有参考的中央“接口”项目。那么myLogger只能通过ILogger接口使用，日志模块可以选择具体ILogger提供哪个。你不应该请求具体的类——这违背了 DI 的目的。

通常，当您实施一项新服务时，您应该已经知道您需要哪些依赖项。如果您不知道应该使用什么，请询问知道的人。这相当于拥有足够的文档——依赖智能感知会给你一个非常肤浅的想法，你应该把什么作为依赖。相反，您应该查阅文档或了解该领域的人。

于 2013-02-14T11:11:16.577 回答