Il generale su mvc ... il controller deve passare i dati per visualizzare o visualizzare dovrebbe prenderlo direttamente dal modello?

Question

Sto cercando di imparare e comprendere appieno il pattern mvc e di imparare php allo stesso tempo. Ho deciso di creare un framework mvc di base che potrei utilizzare in seguito su vari progetti. Avendo letto molti post qui riguardo al mvc e all'accoppiamento tra modelli/viste/controller, mi sento un po 'perso .. Al momento la mia comprensione è che nei controller di applicazioni web si tratta di una richiesta proveniente dal browser e, se necessario, chiama i metodi su classi modello che dicono ai modelli di cambiare il suo stato. Quindi il controllore istanzia una classe di visualizzazione appropriata che sarà responsabile della visualizzazione dell'interfaccia. Ecco il bit non capisco ...

1. Ora dovrebbe passare controllore oggetto modello appropriato per visualizzare e vista dovrebbe tirare fuori tutti i dati dal modello in caso di necessità?

2. Oppure il controller deve prelevare i dati dal modello e passarli alla vista, eventualmente avvolgendoli tutti in un unico oggetto wrapper che la vista accederà e acquisirà i dati da lì?

3. O la vista dovrebbe semplicemente creare un'istanza del modello appropriato quando necessario e estrarre i dati direttamente dall'oggetto del modello?

Da quello che ho letto qui

http://www.phpwact.org/pattern/model_view_controller

sarei magra verso il 3 ° opzione in cui controllore non passa nulla a che vedere e visualizzare un'istanza del modello di cui ha bisogno. Questo perché:

1. vista e controllore dovrebbero avere pari accesso al modello

2. controller non dovrebbe agire semplicemente come mediatore tra vista e modello.

C'è davvero un modo corretto per farlo o dipende piuttosto dal progetto? Inoltre quale approccio consiglieresti a qualcuno che abbia una comprensione decente di OOP, ma è relativamente nuovo per PHP e non troppo chiaro per l'architettura di mvc. O forse dovrei andare con quello che sembra giusto per me e imparare dai miei errori (vorrei comunque evitare questo);)?

Ora, per favore fatemi sapere se la mia domanda non è chiara proverò a spiegare meglio quindi .. Ho letto anche molti post su StackOverflow e numerosi articoli su diversi siti, ma apprezzerebbero comunque l'aiuto quindi grazie in anticipo a tutti risposte.

Answer 1

Personalmente, sono sempre stato un sostenitore del n. La vista non dovrebbe interessare al controller. La vista non dovrebbe avere alcuna dipendenza dal controller per quella materia. Dovrebbe fare ciò che dovrebbe fare, mostrare una vista del modello.

Il flusso di controllo di base dovrebbe essere così: Il controller riceve una richiesta da un browser. Apporta qualsiasi aggiornamento al modello, che è rilevante, e quindi seleziona una vista. Il controllo viene quindi passato alla vista, che ottiene i dati dal modello e li esegue il rendering.

Come interno, l'input dell'utente può essere considerato parte del modello e sia il controller che la vista potrebbero leggerlo. Il punto chiave da prendere è che Controller e View non dovrebbero avere alcuna dipendenza l'uno dall'altro. Ecco perché il pattern è chiamato MVC.

Ora, personalmente, trovo MVC un po 'noioso, e di solito confondo Controller e View più di questo. Ma questo non è davvero MVC.

Answer 2

Personalmente, sono sempre stato un sostenitore del n. La vista non dovrebbe interessare al modello. La vista non dovrebbe avere alcuna elaborazione per quella materia. Dovrebbe fare ciò che dovrebbe fare, formattare i dati.

Il flusso di controllo di base dovrebbe essere così: Il controller riceve una richiesta da un browser. Elabora la richiesta, decide quali dati sono necessari e la recupera dal/i modello/i. Passa quindi i dati nella vista che formatta i dati e li visualizza.

Come interno, l'input dell'utente viene elaborato all'interno del controller e salvato in un modello, se necessario, quindi il feedback viene inserito in una vista, ecc. Il punto chiave da prendere è che l'elaborazione avviene all'interno del controller.

Answer 3

Ho avuto una domanda molto simile in precedenza.Trovo utile pensare a come segue:

MVC 
Model -- Data store, alerts Views of changes 
View -- Displays model, provides hooks for user interaction 
Controller -- Handles user input 

Si potrebbe usare MVC più spesso in applicazioni non-web, dove un sacco di classi interagiscono con la vicenda simultanea.

In un'applicazione web MVC significa MVT (Model-View-Template)

Model -- Strictly a data store, typically an ORM solution 
View -- Handles web requests, provides for user input/output 
Template -- Actually displays content (HTML, Javascript, etc.) 

Così in un'applicazione web la presentazione viene gestito nel modello, la logica dietro l'applicazione viene gestito nella vista (o classi chiamate dalla vista) e il modello è responsabile della conservazione dei dati.

Answer 4

Web MVC e Desktop MVC sono due animali molto diversi.

In Web MVC, un collegamento in una vista chiama un metodo su un controller, che aggiorna un modello e quindi reindirizza a una vista appropriata, che apre un modello e mostra di cosa ha bisogno.

In un MVC desktop, l'opzione 3 è errata perché sia ​​la vista che il modello devono utilizzare lo stesso riferimento. Nel Web, non c'è scelta.

L'opzione numero 2 non è MVC. È MVP, in cui il Presenter è un mediatore.

Un controller dispone di accesso in scrittura a un modello; una vista ha solo accesso in lettura.

Answer 5

Questa è una domanda molto interessante. Dalla mia esperienza maggior parte delle implementazioni in php assegna una variabile modello per la vista:

$this->view->my_property = $modelObj->property 

Questa è una pratica comune. Il ragionamento comune per questo è che se si invia l'oggetto, è possibile chiamare metodi che modificano l'oggetto dalla vista.

//in the controller file 
$this->view->myObject = $modelObj; 

//in the view file, you could call an object modifying method 
$this->myObject->delete(); 

E modificando il modello dal punto di vista è considerato una cattiva pratica. Alcune persone non vogliono che i loro progettisti possano chiamare i metodi di modifica del modello dalla vista.

Detto questo. I non concordano con la pratica comune e tendono ad assegnare l'intero oggetto alla vista e visualizzarlo da lì. E mi disciplina solo per non fare operazioni lì.

E una terza opzione è assegnare l'intero oggetto alla vista. ma alcuni come negli oggetti disabilitano i metodi quando vengono chiamati dalla vista.

Answer 6

Tendo ad avere il controller come intermediario tra il modello e la vista, ma in genere questa è letteralmente una singola riga di codice che collega i tre insieme. Se il modello, la vista e il controller sono correttamente disaccoppiati, dovrebbe fare ben poca differenza.

Answer 7

penso che questo è solo un generico discutere su ciò che è meglio "push" o "tirare" modello. Non esiste una soluzione "assolutamente" migliore.

Answer 8

Il motivo per cui così tanti sviluppatori oggi non riescono a far battere MVC è perché l'abbreviazione di MVC è stata erroneamente dichiarata sin dal primo giorno quando è arrivata allo sviluppo del software, ma il concetto è corretto allora e anche oggi. Dato che vengo dalla vecchia scuola, lascia che te lo spieghi; quando crei un oggetto, per prima cosa crei un modello in modo che il cliente possa visualizzarlo, una volta approvato, avrai pieno controllo su come l'oggetto verrà realizzato. Ecco com'è oggi nella produzione del prodotto.

In sviluppo di applicazioni web di oggi tale termine dovrebbe essere VCM. Perché! Si visualizza cosa c'è nel browser Web e quindi si fa clic su un pulsante per l'azione, noto come Controller. Il controller avverte il modello, che è l'istruzione o la logica per produrre un risultato (questo è il tuo script). Il risultato viene quindi inviato all'utente per la visualizzazione. Nell'ingegneria del software, è possibile fare riferimento ad esso come CMV; perché l'utente non sarà in grado di visualizzare nulla finché le app non verranno compilate e installate. Quindi avremo bisogno di un dispositivo di controllo (PC); il sistema operativo come modello e un monitor per visualizzare i risultati. Se riesci a capire questi concetti, MVC dovrebbe iniziare a sembrare molto più appetitoso. Spero che questo concetto possa aiutare qualcuno a capire MVC.