假设我想要实现一个基于 Uncle Bobs Clean Architecture 的 ASP.NET 应用程序。据我了解：
- Asp.Net 本身将属于框架圈
- Asp.Net 控制器位于网关/接口适配器层
- 我的业务逻辑将位于用例/实体层
依赖规则规定只允许从外圈到内圈的依赖。
据我了解，依赖关系规则不仅与控制流有关，而且与一般的代码级依赖关系有关。
但是：为了在“网关”圈中拥有一个 Asp.Net 控制器，它必须从 Asp.Net Controller 类派生。
问题：这是否会违反依赖关系规则，因为这会引入从“网关”圈到“框架”圈的编译时依赖关系？
Update:我在最近的博客文章中更详细地讨论了这个问题https://plainionist.github.io/Implementing-Clean-Architecture-AspNet/ https://plainionist.github.io/Implementing-Clean-Architecture-AspNet/
是的，它违反了规则。
但框架供应商并不关心这一点，相反，他们努力让我们的应用程序供应商锁定在他们的框架上。
因此我们应该根据项目需求来选择我们的技术栈，包括框架。如果要求我们快速创建原型，我们就需要选择一个能够帮助我们做RAD的框架。如果需求告诉我们业务概念已经建立并且应用程序将长期存在，那么我们需要选择一个框架，使我们的应用程序能够与框架和其他工具解耦，以便我们可以轻松更新和/或交换工具，包括框架。
例如，Symfony 允许我们将控制器与框架耦合或解耦。当谈到 ORM 时，我们也遇到这个问题，Propel 迫使我们拥有扩展 Propel 实体的实体，而 Doctrine 允许我们拥有完全不知道 ORM 的实体。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
