design-patterns - 依赖注入(inject)将业务层内部暴露给 UI 层——这肯定是一件坏事吗？

Question

我目前正在使用依赖注入(inject)。实际上，这涉及到 UI 层(例如 Web 应用程序)，包括一个 DI 容器，该容器具有关于它将使用的接口(interface)的一大堆数据，以及每个接口(interface)使用的实现。

但是，由于需要满足依赖关系，DI 容器还需要了解它本来不需要访问的接口(interface)和类。例如:

UI 层需要使用IWidgetManager 接口(interface)。配置的实现是 ConcreteWidgetManager。这是在 DI 容器中注册的。

ConcreteWidgetManager 依赖于 IWidgetRepository。所需的实现是 ConcreteWidgetRepository。因此，DI 容器还必须知道 IWidgetRepository 和 ConcreteWidgetRepository。

如果我简单地将 ConcreteWidgetManager 对 ConcreteWidgetRepository 的依赖性硬编码，那么 ConcreteWidgetRepository 可以成为内部的，因此对我的 UI 层不可见。没有任何 UI 代码可以绕过管理层并直接与存储层一起工作。

因此，从 UI 层的角度来看，尽管 DI 的使用在许多方面都是一种很棒的模式，但它似乎破坏了封装。

我的想法是否正确，有什么办法可以缓解这种情况吗？

Answer 1

不，依赖注入(inject)并没有破坏封装。正是您对应用程序进行分层的方式破坏了封装。通过分离不同程序集中的接口(interface)和实现并将容器配置放在其自己的程序集中，您可以避免 UI 层必须依赖具体的 ConcreteWidgetManager，甚至是 IWidgetRepository 如果你愿意的话。

但是，添加额外的组件是有成本的。无论是维护还是编译解决方案所需的时间。我不会使用程序集强制执行体系结构规则，而是使用清晰简单的指南或可能使用诸如 NDepend 之类的工具来强制执行它们。然而，当团队足够小时，使用代码审查将足以有效地防止架构侵 eclipse 。