Sto concettualmente cercando di capire se dovrei farlo:
item = Model()
screen = View()
brain = Controller(item, screen)
o questo..
brain = Controller()
item = Model(brain)
screen = View(brain)
o questo..
class Controller():
def __init__(self):
item = Model(self)
screen = View(self)
o qualcos'altro interamente?
Risposte:
Per me, la prima opzione ha senso. Il compito del controller è di coordinare tra la vista e il modello. Da quel punto di vista, ha senso che il controller sia quello che controlla i riferimenti alla vista e al modello.
Non puoi davvero avere un controller senza un modello e una vista, tuttavia ha molto più senso avere semplicemente una vista o semplicemente un modello (ad esempio, nel test di unità). Ecco perché vuoi passare quelle dipendenze nel controller e non le altre due.
I Modele Viewsono indipendenti l'uno dall'altro.
Non pensare a Controllercome il cervello della struttura MVC. Pensalo come il dispatcher che gestisce le richieste dal browser e le invia al Model. Prende quindi i dati dal Modele li impacchetta in un modello amichevole, e poi li invia a View.
Il Modelè il cervello della struttura MVC, e questo è dove si dovrebbe mettere le regole aziendali. Le regole aziendali sono comuni a più controller . Pertanto, un controller di documenti e un controller di report possono entrambi utilizzare un modello utente per vedere chi ha accesso a tali elementi. Non vorrai ripetere quelle regole in entrambi i controller.
L' Viewdovrebbe utilizzare un modello HTML per presentare i dati in modo specifico non datasource. Non dovrebbe essere strettamente legato allo schema del database. Per mostrare il titolo di un documento avresti la vista in uscita il contenuto di una variabile modello chiamata document_title, e solo il Controllersa come è stata impostata quella variabile e solo il Modelperché il documento ha quel titolo.
MVC è stato originariamente definito per facilitare la programmazione delle applicazioni desktop. La vista si è iscritta agli eventi del modello, aggiornando la presentazione quando il modello è cambiato. Il controller ha semplicemente tradotto gli eventi dell'interfaccia utente (ad es. Premendo un pulsante) in chiamate al modello. Quindi il controller e la vista dipendevano dal modello, ma erano indipendenti l'uno dall'altro. Il modello era indipendente da entrambi. Ciò ha consentito a più viste e controller di funzionare sullo stesso modello.
L'architettura "MVC" utilizzata per le applicazioni web 1.0 (aggiornamento di pagina intera, no AJAX) è leggermente diversa. Una richiesta Web viene inviata a un controller. Il controller modifica in qualche modo lo stato del modello, quindi invia uno o più modelli per il rendering da una vista. Il controller e la vista dipendono entrambi dal modello, ma anche il controller dipende dalla vista.
Con le applicazioni web 2.0, stiamo tornando alla classica architettura MVC, sul lato client . Il modello, la vista e il controller risiedono tutti sul lato client come oggetti Javascript. Il controller traduce gli eventi dell'utente in azioni modello. Le azioni del modello possono o meno comportare una richiesta AJAX al server. Ancora una volta, la vista si abbona agli eventi del modello e aggiorna la presentazione di conseguenza.
La vista dovrebbe iscriversi alle modifiche nel modello. Vi è latitudine nella ricchezza degli abbonamenti in quanto possono essere dettagliati (mostrami le variazioni di inventario per questo particolare articolo) o generici (il modello è cambiato); la vista potrebbe interrogare il modello in risposta alla notifica di modifica. La vista presenta il set desiderato di elementi del modello sullo schermo, aggiornando lo schermo come quando si gestiscono le notifiche di modifica.
Il controller dovrebbe inviare le modifiche al modello, a seguito della direzione dell'utente (ad es. Tastiera in put, comandi mouse e menu).
Il modello mantiene il modello e un elenco di abbonamenti e deve comunicare le visualizzazioni delle modifiche applicabili tramite i loro abbonamenti.
È inoltre necessario un meccanismo per creare nuove viste e controller (poiché in MVC dovresti essere in grado di avere due o più viste dello stesso modello (potrebbero essere la stessa vista (punto) o viste diverse (punti). Logicamente, possiamo considerare che il controller deve eseguire o avere accesso a una fabbrica di view & controller (coppia), che può far parte del controller o di un altro componente.
Modelsnon avvisare Views. Controllersinterrogare il Modelper modifiche e quindi rendono Viewspresentare tali modifiche.
MVC è più simile a un modello di modularità. Il suo scopo è che ogni volta che si desidera modificare il layout dell'interfaccia utente (vista), non è necessario modificare la logica dell'applicazione (controller) o l'elaborazione interna dei dati (modello).
Per raggiungere questo obiettivo, lo schema consiste nell'isolare la logica di implementazione di ciascun componente MVC. Tuttavia, è perfettamente normale che i componenti conoscano le interfacce degli altri .
Quello che ho visto spesso è che il controllore crea o chiama il modello e la vista (quindi conosce la loro interfaccia) e il modello o la vista può avvisare il controllore in cambio (più come un callback o un modello di osservatore). La parte importante è che il controllore non è a conoscenza della struttura del layout.