Sto concettualmente cercando di capire se dovrei fare questo:
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?
Per me, la prima opzione ha senso. Il compito del Controller è di coordinare tra la vista e il modello. Da questo punto di vista, ha senso che il controller sia quello che controlla i riferimenti alla vista e al modello.
Non puoi avere un controller senza un modello e una vista, tuttavia ha molto più senso avere solo una vista o semplicemente avere un modello (ad esempio, nel test delle unità). Ecco perché vuoi passare queste dipendenze al Controller e non agli altri due.
Model e View sono indipendenti l'uno dall'altro.
Non pensare a Controller come al cervello della struttura MVC. Consideralo come il dispatcher che gestisce le richieste dal browser e invia a Model . Prende quindi i dati da Model e li impacchetta in modo amichevole modello , quindi li invia a View .
Il Model è il cervello nella struttura MVC, ed è qui che devi inserire le tue regole aziendali. Le regole aziendali sono comuni su più controllori . Quindi un controller document e un report controller possono entrambi utilizzare un modello Utente per vedere chi ha accesso a queste cose. Non vorrai ripetere queste regole in entrambi i controller.
Il View dovrebbe utilizzare un modello HTML per presentare i dati in un modo specifico non di origine dati. Non dovrebbe essere strettamente legato allo schema del tuo database. Per mostrare il titolo di un documento, la vista mostra il contenuto di una variabile di modello chiamata document_title , e solo Controller sa come è stata impostata la variabile, e solo Model sa perché quel documento ha quel titolo .
MVC è stato originariamente definito per facilitare la programmazione delle applicazioni desktop. La vista è stata sottoscritta per modellare eventi, aggiornando la presentazione quando il modello è cambiato. Il controller ha semplicemente tradotto gli eventi dell'interfaccia utente (ad esempio una pressione di un pulsante) nelle 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 lavorare sullo stesso modello.
L'architettura "MVC" utilizzata per le applicazioni Web 1.0 (aggiornamento pagina intera, senza 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 da renderizzare da una vista. Il controller e la visualizzazione dipendono entrambi dal modello, ma il controller dipende anche 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 sul lato client come oggetti Javascript. Il controller traduce gli eventi utente in azioni del modello. Le azioni del modello possono o non possono risultare in una richiesta AJAX al server. Di nuovo, la vista si abbona agli eventi del modello e aggiorna la presentazione di conseguenza.
La vista dovrebbe iscriversi alle modifiche nel modello. C'è latitudine nella ricchezza degli abbonamenti in quanto possono essere dettagliati (mostrami i cambiamenti di inventario per questo particolare articolo) o generici (il modello è cambiato); la vista può interrogare il modello in risposta alla modifica della notifica. 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 modifiche al modello, come risultato della direzione dell'utente (ad esempio comandi di tastiera in put, mouse e menu).
Il modello mantiene il modello e un elenco di abbonamenti e deve notificare le visualizzazioni delle modifiche applicabili tramite le loro sottoscrizioni.
Ci deve essere anche un meccanismo per creare nuove viste e controller (dato che in MVC dovresti essere in grado di avere due o più viste dello stesso modello (potrebbero essere la stessa vista (punto) o diversa vista (punto) s) Logicamente, possiamo considerare che il controller deve eseguire o avere accesso a una vista e un controller (coppia) di fabbrica, che possono far parte del controller o di un altro componente.
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 le elaborazioni dei dati interne (modello).
Per ottenere questo risultato, lo schema consiste nell'isolare la logica di implementazione di ciascun componente MVC. Tuttavia, è perfettamente normale che i componenti si conoscano le interfacce .
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 possono avvisare il controllore in cambio (più come un callback, o pattern di osservatore). La parte importante è che il controllore non è a conoscenza della struttura del layout.
Leggi altre domande sui tag mvc