MVC: isolamento della vista e della logica del modello

La prima cosa da capire è che il disaccoppiamento tra il modello e la vista è solo a senso unico. Il modello non dovrebbe preoccuparsi di come i suoi dati sono presentati al mondo esterno (dovrebbe essere inconsapevole della vista se non sapere qualcosa sta osservando il modello).
D'altro canto ha una conoscenza del modello, in particolare su come estrarre i dati da esso.

In un mondo ideale, il modello dovrebbe esporre i suoi dati in un modo conveniente per il modello e i concetti che rappresenta. La vista deve essere conforme all'API del modello.

Nel mondo reale, le persone vorranno riutilizzare i widget tra diversi progetti, in modo da ottenere librerie di widget che si aspettano una determinata API comune dal modello con cui lavorano, spesso sotto forma di un'astrazione generica come un elenco, tavolo o albero. In questi casi, è spesso più semplice lasciare che il modello rifletta l'astrazione generica che meglio si adatta (con l'API comune associata) e per aumentare l'interfaccia laddove appropriato.
Sebbene l'API del modello sia stata adattata per soddisfare le aspettative di visione comune, i due sono ancora disaccoppiati, perché il modello non sa quale porzione del modello viene effettivamente presentata nella vista e come viene presentata.

Ti manca un livello. Hai bisogno di un controller. Il compito del controllore è quello di prendere i dati dal modello, qualunque sia l'astrazione del modello, e quindi utilizzare tali dati per popolare la vista, fare la logica della pagina, ecc. MVC è il paradigma modello / vista tradizionale. La mia applicazione web, qui , è scritta in python e ha uno svantaggio di un MVC framework chiamato Web.py. Puoi vedere il modo in cui i modelli e le viste sono separati da un livello controller, che controlla la vista.