DI在分层应用中与隔离

Question

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

问题在于数据层的DI注册。组合根在UI中，我不想在那里有任何数据引用。我找到了answer。据我所知，我们应该引用所有层，并认为它们是库而不是层。这样我可以指定我的业务层使用数据层或我想要的任何其他内容。毕竟这就是DI的原因。

这是正确的，但有一个问题！我们不应该在UI上使用数据层。但是，一旦开发人员意外地从UI引用到Data，而另一个开发人员直接从Data层向UI类注入了一些东西。所以他跳过了我从未想过的业务层。

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

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

这里最好的模式是什么？

Answer 1

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

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

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

真正的问题是，这值得吗？如果你想要这样做以防止不得不进行代码审查，你就是在欺骗自己。