dependency-injection - 具有隔离的分层应用程序中的 DI

Question

假设我们有三层；用户界面、业务、数据。我们正在使用 DI。我不希望从 UI 访问数据层。

问题是关于数据层的DI注册。组合根在 UI 中，我不想在那里对 Data 有任何引用。我找到了这个答案。据我了解，我们应该参考所有层，并认为它们是库而不是层。这样我可以指定我的业务层使用数据层或我想要的任何其他东西。毕竟这就是 DI 存在的原因。

没错，但是有问题！我们不应该在 UI 中使用数据层。但是一旦一个开发者不小心从 UI 引用到了 Data，而另一个开发者直接从 Data 层注入了一些东西到一个 UI 类中。所以他跳过了我从不想要的业务层。

我该如何处理这种情况？我想有一些限制，但另一方面我想要 DI 的灵活性。

当然，有些人认为我们可以有一个单独的库，只用于依赖注册。

这里最好的模式是什么？

Answer 1

您链接到的答案有两个答案，说明在同一个程序集中拥有组合根和 UI 层不是问题：

• 您将逻辑层误认为是物理边界：程序集是部署单元，可以包含多个逻辑层。层甚至可以分布在组件中。想想4+1 的观点。组合根可能与您的 UI 在同一个程序集中，但它不在 UI 层中，尽管组合根依赖于数据访问层，但 UI 层不依赖于（尽管它的程序集确实如此）。
• 进行代码审查对于质量或您的软件以及团队内的知识共享非常重要。如果您现在不进行代码审查，那么您绝对应该开始进行。这些代码审查可以包括对架构准则的检查，例如您在问题中描述的规则。
• 虽然程序集分离为您提供编译时支持，但编译器无法检查大多数体系结构规则。此外，当开发人员添加对 DAL 程序集的引用时，编译器不会报错。开发人员总能找到打破规则的方法。同样，代码审查有很大帮助。此外，作为架构师，您可以开始使用 NDepend 等工具来自动验证某些架构规则。但是，当您应用构造函数注入时，也可以使用单元测试，因为可以通过简单地反映 UI 层中类型的构造函数来找到依赖关系。

但是，如果您认为这是一个问题，为什么不直接将 UI 层移动到它自己的程序集中呢？启动程序集不需要有 UI 层！如果您创建 Windows 窗体应用程序，请将所有窗体移动到它们自己的程序集中。如果您正在创建 ASP.NET MVC 应用程序，请将控制器和视图移动到它们自己的程序集中。根据您正在构建的应用程序的类型，您必须应用某些技巧才能使其正常工作，但对于 .NET 中的大多数项目类型，这是可能的。

真正的问题是，这值得麻烦吗？如果您希望这样做是为了避免进行代码审查，那您就是在自欺欺人。