清洁架构中网关到框架的依赖关系答案

【问题标题】：Dependency from Gateway to Framework in Clean Architecture清洁架构中网关到框架的依赖关系
【发布时间】：2018-07-13 08:08:07
【问题描述】：

假设我想要实现一个基于 Uncle Bobs Clean Architecture 的 ASP.NET 应用程序。据我了解：

依赖规则说只允许从外圈到内圈的依赖。

据我了解，依赖规则不仅与控制流有关，而且通常与代码级别的依赖有关。

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

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

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

【问题讨论】：

【解决方案1】：

是的，它违反了规则。

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

因此我们应该根据项目需求选择我们的技术栈，包括框架。如果要求我们快速创建原型，我们需要选择一个可以帮助我们做 RAD 的框架。如果需求告诉我们业务概念已经确立并且应用程序将长期存在，我们需要选择一个框架，让我们的应用程序与框架和其他工具保持解耦，以便我们可以轻松更新和/或交换工具，包括框架。

例如 Symfony 允许我们将控制器耦合或解耦到框架。谈到 ORM，我们也有这个问题，Propel 迫使我们拥有扩展 Propel 实体的实体，而 Doctrine 允许我们拥有完全不知道 ORM 的实体。

【讨论】：

感谢您的回答。我想我会将我的控制器拆分成一个瘦的 Asp.Net 控制器，它基本上只是将调用转发给我的实际控制器，然后它是无框架的，专注于数据转换
这就是 Bob 大叔所提倡的——依赖倒置。该框架要求您依赖它提供的某些接口/API，因此您要做的是在应用程序层（“控制器”）定义自己的接口，并在框架层中创建一个实现该接口和框架接口的类，充当两者之间的桥梁。