干净架构中从网关到框架的依赖性

Question

让我们想象一下，我想基于Uncle Bobs Clean Architecture实现一个ASP.NET应用程序。据我了解：

• Asp.Net本身将在框架圈内
• Asp.Net控制器将位于网关/接口适配器层中
• 我的业务逻辑将在用例/实体层中

依赖性规则说，仅允许从外圈到内圈的依赖性。

据我了解，依赖性规则不仅与控制流有关，而且还与代码级依赖性有关。

但是：为了使“网关”圈子中有一个Asp.Net控制器，必须从Asp.Net Controller类派生。

问题：这不会违反依赖性规则，因为这会导致从“网关”圈子到“框架”圈子的编译时依赖性吗？

更新：我在最近的博客文章https://plainionist.github.io/Implementing-Clean-Architecture-AspNet/中更详细地讨论了这个问题

Answer 1

是的，这违反了规则。

相反，框架供应商并不关心它，相反，他们努力使我们的应用程序供应商锁定其框架。

因此，我们应根据项目要求选择技术框架，包括框架。如果要求我们快速创建原型，则需要选择一个可以帮助我们进行RAD的框架。如果需求告诉我们已经建立了业务概念，并且该应用程序可以长期使用，那么我们需要选择一个框架，该框架可以使我们的应用程序与框架和其他工具保持分离，以便我们可以轻松地更新和/或交换工具，包括框架。

例如，Symfony允许我们将控制器耦合或解耦到框架。当涉及到ORM时，我们也遇到了一个问题，即Propel迫使我们拥有扩展Propel实体的实体，而Doctrine则使我们拥有的实体完全不知道ORM。