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

时间:2013-02-13 14:21:58

标签: dependency-injection ninject ninject-2

在使用DI框架的大型项目中(例如我的Ninject),在实现新的“服务”时,存在哪些选项可以找出其他“服务”可用作依赖项。在使用DI之前我已经注意到我们的代码库中有一个趋势是获得对“god”对象的引用,该对象几乎可以访问所有可用的功能,然后Visual Studio的IntelliSense将变得非常有助于发现所有可用的东西(显然这只有在最初拥有这样一个对象的糟糕架构决策时才能实现这种方法。

我可以得到一些可能的答案,并且对他人的工作感兴趣:

  1. 你应该知道你正在运作的整个系统 了解其他类/服务的存在(例如,如果我有 静态类我只需知道它们的存在就可以了 使用它们。)
  2. 您保持良好的外部文档 代码库,以便所有开发人员都能理解所有类/服务 (这会给我带来很大的文档负担,在我看来)。
  3. 创建API以查询DI容器(Ninject内核)以获取列表 所有绑定,以查看可用的服务(可能只有 单身)。这也可以作为构建系统的一部分来完成 开发人员在每次构建时自动生成文档 可以参考。
  4. 这对其他开发者来说一直是个问题吗?

2 个答案:

答案 0 :(得分:1)

通常,您不希望系统中存在所有服务,然后选择其中一个。您想要访问功能。使用命名空间以一种方式构造您的类,以便在哪里查找它。

E.g。如果我想知道.NET中可用的集合,请输入System.Collections.Generic.,IntelliSense为我提供了一个选项列表。

答案 1 :(得分:0)

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

通常,当您实施新服务时,您应该已经知道您需要哪些依赖项。如果您不知道应该使用什么,请问某人。这相当于拥有足够的文档 - 依赖intellisense会让您对作为依赖项应该采取的内容有一个非常浅薄的概念。相反,您应该查阅文档或了解该区域的人。