Clean Architecture and MVC controllers + entities

Question

In Uncle Bob's clean architecture, why can't MVC controllers call entities directly? It seems like since the controller depends on the inner layer, they should be able to call entities when needed. If the entity has to change for something in the presentation layer,then you'd add another class to handle that,is this correct?

Answer 1

MVC: Model-View-Controller.

• Model: Data model / Entity manager
• View: Presentation layer
• Controller: Business & application logic

I read your question and to me it seems to be asking "Why can't the Controller just call the Entity directly ?". By adopting the MVC-Paradigm, you created a contract for different components to marshal responsibility for different tasks or aspects of the application.

This is what a framework does for you -- it encapsulates or groups core functionality and is pretty well known as the 'separation of concerns'. Separating concerns allows for much easier downstream refactoring, maintenance, upgrades, and fixes. This is pretty much the entire reason we like frameworks.

In the scenario you described, I'd have to say "No. You don't add (entity) classes to handle changes for the UI. Instead, you'd extend your View's to accommodate the additional data in the entities.". Similarly, if you need to add functionality to the entity(ies), you add or change classes in your Model layer. The same concept applies to your Controllers, if you need to support a feature in the UI -- the business part goes in the controller.

The reason your your Controller's need to participate in the framework and access Entities via the Model (data model) is so that you adhere to the framework. If you don't leverage the functionality of the framework, why even have one ?

PS: It's also known as "...eating your own dog food..."