Let's imagine I would want to implement an ASP.NET application based on Uncle Bobs Clean Architecture. As far as I understood it:
- Asp.Net itself would be in the framework circle
- An Asp.Net controller would be in the gateways/interface adapters layer
- my business logic would be in the usecases/entities layer
The dependency rule says only dependencies from outer circles to inner circles are allowed.
As i understood it the dependency rule is not just about control flow but about code level dependencies in general.
BUT: in order to have an Asp.Net controller in the "gateways" circle it would have to derive from Asp.Net Controller class.
Question: wouldn't that violate the dependency rule as this introduces a compile time dependency from "gateways" circle to "frameworks" circle?
Update: I have discussed this question in more detail in my recent blog post https://plainionist.github.io/Implementing-Clean-Architecture-AspNet/
Yes, it breaks the rules.
Framework vendors don’t care about it though, on the contrary, they strive from having our applications vendor locked to their frameworks.
Therefore we should choose our tech stack, including framework, according to the project requirements. If it is a requirement that we create a prototype quickly, we need to choose a framework that helps us do RAD. If the requirements tell us that the business concept is established and the application will live for a long time, we need to choose a framework that allows us to keep our application decoupled from the framework and other tools, so that we can easily update and/or swap tools, including the framework.
For example Symfony allows us to have controllers coupled or decoupled to the framework. When it comes to ORMs we also have that problem, where Propel forces us to have entities extending the Propel entities, while Doctrine allows us to have entities completely unaware of the ORM.
来源：https://stackoverflow.com/questions/48589192/dependency-from-gateway-to-framework-in-clean-architecture