1

假设我正在构建一个将一些配置存储在数据库中的软件。我的业务规则、页面等都在我称之为Core的项目中。我有另一个项目，称为Configuration，它具有访问数据库的所有必要方法。所以：

             BusinessComponent                     ConfigurationProvider
       +---------------------------+           +---------------------------+
       |                           |           |                           |
       |                           |  ---->    |                           |
       |                           |           |                           |
       +---------------------------+           +---------------------------+

配置对象通过接口注入IConfiguration到业务组件中。

        BusinessComponent              IConfigurationProvider              ConfigurationProvider
  +--------------------------+      +---------------------------+      +---------------------------+
  |                          |      |                           |      |                           |
  |                          | ---> |                           | ---> |                           |
  |                          |      |                           |      |                           |
  +--------------------------+      +---------------------------+      +---------------------------+

所以，从某种意义上说，两者BusinessComponent都ConfigurationProvider取决于IConfigurationProvider。

问题是，core或Configuration应该在这两个项目中的哪一个IConfigurationProvider？

我认为，在使用 DI 时，最好让项目通过创建接口来声明它的依赖关系，然后有兴趣提供这些实现的项目添加对这个项目的引用。它看起来绝对像一种“可扩展性”方法。（这是依赖倒置的一种形式，不是吗？）

但是，当您有多个依赖于相同配置的项目时，这种方法会变得很奇怪——IConfigurationProvider在这种情况下，我们将有两个类似的声明。

很抱歉，如果以前有人问过这个问题，但我一直找不到。

4

1 回答 1

0

我认为您应该考虑拥有一个包含所有接口的不同项目/程序集，并且您的其他项目将引用该项目。这也将作为一个 SDK 程序集，您可以将它提供给任何希望提供自己的实现的人，而无需分发几个也包含您自己的实现的大型程序集。

于 2013-08-17T15:59:34.100 回答