Nell'architettura pulita di Uncle Bob, perché i controller MVC non possono chiamare le entità direttamente? Sembra che dal momento che il controller dipende dal livello interno, dovrebbero essere in grado di chiamare le entità quando necessario. Se l'entità deve cambiare qualcosa nel livello di presentazione, devi aggiungere un'altra classe per gestirla, è corretta?
MVC: Model-View-Controller.
Ho letto la tua domanda e sembra che mi stia chiedendo "Perché il Controller non può chiamare direttamente l'Entità?". Con l'adozione di MVC-Paradigm, è stato creato un contratto per componenti diversi per la responsabilità di incarichi per diversi compiti o aspetti dell'applicazione.
Questo è ciò che fa per te un framework: incapsula o raggruppa funzionalità di base ed è piuttosto noto come " separazione delle preoccupazioni ". Separare le preoccupazioni consente di semplificare il refactoring a valle, la manutenzione, gli aggiornamenti e le correzioni. Questo è praticamente il motivo per cui abbiamo come frameworks.
Nello scenario che hai descritto, dovrei dire "No. Non aggiungi classi (entità) per gestire le modifiche per l'interfaccia utente, ma estendi le tue View per accogliere i dati aggiuntivi nelle entità . ". Allo stesso modo, se è necessario aggiungere funzionalità all'entità (o alle), si aggiungono o si modificano le classi nel livello del modello. Lo stesso concetto si applica ai controller, se è necessario supportare una funzionalità nell'interfaccia utente: la parte aziendale entra nel controller.
Il motivo per cui il tuo controllore deve partecipare al framework e accedere alle entità tramite il modello (modello di dati) è tale da rispettare il framework. Se non sfrutti la funzionalità del framework, perché ne hai anche uno?
PS: è anche conosciuto come " ... mangiando il tuo cibo per cani ... "
Leggi altre domande sui tag clean-code architecture