Qual è il lavoro del controller in MVC?

Question

Sto cercando di imparare l'architettura MVC. Ma non sono in grado di capire perché hai bisogno di un controller. Vedere il codice seguente per il mio modello e la vista.

model.php si collega al database e recupera il post. view.php mostrerà solo il post.

model.php

<?php 
    $db = mysql_connect("somehostname", "someuser", constant("somepassword")); 
    mysql_select_db("somedatabase", $db); 

    $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'"); 
    $row = mysql_fetch_array($result); 

    $post = $row["post"]; 

    mysql_close($db); 
?> 

view.php

<?php 
    require "model.php"; 
    echo $post; 
?> 

ho impostato la mia posizione browser per http://whateverhost/view.php?id=5

Questo carichi post con l'id 5. Non ho bisogno di un regolatore di qui . Quindi sono confuso perché hai bisogno di un controller?

Nota: spiegare con riferimento all'esempio precedente. Non sono un fanatico della programmazione e l'apprendimento di cose come CakePHP, ecc. È travolgente per me.

Modifica: Sarebbe bello se è possibile aggiungere controller.php al codice precedente. Questo mi aiuterebbe a capire il ruolo di un controller e come comunica con il modello e le visualizzazioni.

Answer 1

Non hai bisogno di un controller perché il tuo esempio è banale. Un esempio di uno scenario caso reale:

Supponiamo di avere un'applicazione CAD. L'applicazione CAD è organizzata come MVC. Hai:

• una vista che è responsabile per il disegno del modello corrente e fornire entità cliccabili.
• un modello, che mantiene i dati correnti da rappresentare
• un controller, il cui ruolo è quello di ottenere gli eventi dalla vista e convertirli in entità adeguate in modo da modificare il modello.

Ad esempio, l'utente fa clic su un quadrato e lo elimina. Il controller riceverà l'evento dalla vista, crea un oggetto che rappresenta un comando (tramite il comando Command), lo aggiunge in una coda per la funzionalità di annullamento ed esegue il comando. Il comando modificherà quindi il modello, ma la responsabilità di tradurre gli eventi di visualizzazione nel complesso meccanismo che modifica il modello è sotto la responsabilità del controllore.

Ovviamente si potrebbe dire, perché la vista non crea oggetti Command allora? beh, nessuno te lo proibisce, ma finiresti per avere una logica di presentazione mista a logica operativa. Questo va contro il buon design, anche se per i casi più banali, potresti vivere con questo design. Ad esempio, se l'applicazione CAD ti consente di visualizzare l'elenco di oggetti sia come rappresentazione 3D che come elenco di entità, e puoi eliminare da entrambi, puoi vedere chiaramente che entrambe le viste implementano la stessa logica per gestire il command pattern (bad design), oppure canalizzano lo stesso messaggio su un controller comune (buon design, MVC).

Answer 2

model.php è in questo caso si controller.

I ruoli del modello, vista e il controller non sono facili da distinguere se non si dispone di un buon framework MVC (pianura PHP non è una buona).

Il modello è la struttura dati che viene resa persistente in un DB. In termini di codice, se principalmente consiste in una struttura di dati come classe.

La vista mostra solo i dati. Principalmente html con alcuni tag di scripting.

Il controller controlla cosa succede. Ad esempio, un utente modifica un post. I dati sono ricevuti dal controller, forse modificati un po '(data/ora aggiunta, utenti ip) e inviati al modello per memorizzarlo. Il controller decide quindi quale vista visualizzare e quali dati recuperare per la nuova vista.

Solo un piccolo esempio.

Answer 3

IMHO nella MVC controller ha due scopi principali:

1. Il verificabilità della logica GUI o nulla i trigger GUI. Nella maggior parte dei casi è possibile scrivere test di unità per il controller in modo relativamente semplice, per esempio è molto più difficile per GUI come PHP o Windows Form. Il primo dipende da un browser, il più tardi dipende da Windows Messaggi, entrambi non rendono la vita più facile quando si scrivono i test unitari. È quasi la stessa cosa con qualsiasi altra tecnologia di presentazione.
2. intercambiabilità del livello di presentazione o (in alcuni casi) del controller. Esistono scenari in cui è possibile utilizzare lo stesso controller in due GUI (un modulo "leggero" per un caso speciale e un modulo "ricco" per un altro caso) o viceversa (non così spesso).

In uno scenario con molte più funzionalità rispetto al campione, ne vedrete i vantaggi. Ma dovresti decidere a favore o contro MVC e utilizzare lo stesso approccio in ogni forma di applicazione, non mescolarlo. Preferirei MVC, hai quasi sempre bisogno di logica del controller.

Answer 4

Penso che in questo caso potrebbe esserci un utilizzo per un controller e il codice non lo mostra.

MODELLO:

<?php 
    $db = mysql_connect("somehostname", "someuser", constant("somepassword")); 
    mysql_select_db("somedatabase", $db); 

    $result = mysql_query("SELECT post FROM posts WHERE postid='" . $_POST['id'] . "'"); 
    $row = mysql_fetch_array($result); 

    $post = $row["post"]; 

    mysql_close($db); 

function getPost() { 
    return $post; 
} 
?> 

VISTA:

<html> 
<head></head> 
<body> 
    <input type="submit" onClick="postToScreen();" value="Post"> 
    <p id="post"></p> 
</body> 
</html> 

CONTROLLER:

<?php 
    $controllerPost = getPost(); 
?> 

<script type="text/javascript"> 
function postToScreen() { 
    document.getElementById("post").innerHTML="<?php echo $controllerPost; ?>"; 
} 
</script> 

mia javascript è arrugginito. Penso di aver capito bene quel codice, ma l'ho verificato due volte prima di inserirlo in qualcosa. il controller controlla come appare la vista e, in determinate circostanze, quali dati contiene il modello.

Answer 5

IMO ...

MVC è un design pattern molto generico che non necessariamente dire ciò che è bene e cosa è male. C'è un modello, una vista e un controller. Le responsabilità di ciascuna di queste cose dipendono dal sapore di MVC e il sapore di MVC che scegli dipende dalla complessità del tuo progetto. Ad esempio, se si dispone di un progetto basato sul dominio, gli esempi forniti da altri qui non funzionerebbero molto bene.

Così alla sua base stessa:

Modello: Un oggetto che ha i dati che verranno visualizzati nella vista. Che si tratti di un DTO o di un modello di dominio non è in realtà definito qui, ma condividerò i miei pensieri su questo in un secondo.

Visualizza: è ciò che l'utente vede e il modo in cui l'utente interagisce. Qualsiasi codice o logica qui dovrebbe supportare direttamente la vista. In altre parole logica aziendale ZERO, logica di accesso ai dati ZERO, conoscenza ZERO di tutto ciò che va oltre ciò che l'utente vede fisicamente. O un modulo Web, un modulo finestra desktop o un'attività (mobile) ecc ...

Controller: Probabilmente il pezzo più ambiguo di questo puzzle. Una cosa è certa, media tra la vista e il "modello" e decide anche cosa succederà dopo o meglio, "controlla" il flusso. Ma è importante non portare questa descrizione troppo lontano. Ciò che questa cosa dipende in realtà dipende dalla tua comprensione di MVC. Quindi condividerò il modo in cui lo guardo in un contesto web; ma fondamentalmente, basta tracciare una linea tra il controllo del flusso del servizio e l'esecuzione effettiva del servizio.

MVC, per me, non è un modo diverso di descrivere l'N-livello, come qualcuno potrebbe affermare. Non ci sono livelli in MVC come MVC è effettivamente nel livello di presentazione. Ogni elemento di MVC in realtà vive nel livello di presentazione e il pattern MVC dice solo che si dovrebbe separato le preoccupazioni tra ottenere i dati e la visualizzazione:

• Modello: ciò che i dati assomiglia. Davvero solo una struttura che la vista utilizzerà per ottenere i suoi dati
• Visualizza: Visualizzazione effettiva
• Controller: Calcolare dove ottenere i dati per il modello o anche il modello stesso.

Se si può accettare questa affermazione, allora dovrebbe aiutare a chiarire cosa sia realmente il modello in questo contesto. Il modello NON è un oggetto di accesso ai dati e il modello NON è un modello di dominio perché nessuna di queste cose dovrebbe essere nel livello di presentazione. Quindi questo ci lascia con un ViewModel (MVVM) o un DTO. Ho intenzione di andare con DTO per motivi di semplicità.

Quindi, se abbiamo accettato DTO come tipo di modello di cui stiamo parlando quando diciamo "modello" in MVC, allora dove lo otteniamo? Se il controller non deve interferire con l'accesso ai dati, allora dove? E il tuo livello di servizio? Il tuo livello di servizio contiene tutti i "come" della tua applicazione. È il livello "Fai cose". Quindi, se la tua vista vuole creare un utente, raccoglierà i dati e li consegnerà al controller. Il controllore decide quali servizi chiamare per eseguire l'attività e invia la richiesta con i dati necessari. Il livello di servizio risponde con un DTO. Tale DTO può essere utilizzato direttamente o aggiunto a un altro modello (se sono stati chiamati più servizi, ad esempio).

I punti importanti sono:

• Il controllore non sa nulla del tuo dominio (se ne avete uno), si conosce solo sui propri servizi disponibili e come chiamarli.
• Assolutamente no business la logica viene eseguita dal controller. Ad esempio, se è necessario inviare un'e-mail di benvenuto come parte dell'operazione CreateUser, quella non verrà avviata dal controller poiché si tratta tecnicamente di una regola aziendale. Sarebbe gestito tra il tuo servizio e i livelli del dominio.
• A mio parere, nessun accesso ai dati deve essere eseguito dal controller. Questo dovrebbe essere delegato a un livello di servizio. Molte esercitazioni tendono a mostrare il controller che interagisce con i repository che, a mio avviso, va bene perché si tratta di un'astrazione, ma l'accesso diretto ai dati dovrebbe essere un assoluto no no ovunque nel livello di presentazione.

Ancora, questo in un contesto web. Se stai lavorando con MVC in un'app per Android, forse non avrai un livello di servizio o un dominio. Forse interagirai con una diversa razza di oggetti. Personalmente, utilizzo sempre i livelli di servizio o applicazione e per diversi motivi che possono o non possono essere considerati preziosi per gli altri.

Quindi in MVC.Net, il controller è più simile a un'API; la vista e l'API sono due diversi media di presentazione che hanno lo scopo di funzionare insieme (il controller back-end presenta i dati, il frontend controller crea modelli con tali dati e media con la vista). In Angular, il controller è più simile a ciò di cui stiamo parlando qui. Strati di strati di strati, a quanto pare. È un po 'confuso concettualizzare, ma il concetto non si sposta mai oltre il livello di presentazione.

Ma per riassumere: Il controller "controlla" le operazioni e i dati in entrata e in uscita dal sistema, da e verso la vista ma in realtà NON FARE l'attività. I dettagli di questo processo dipendono in larga misura dalla filosofia di progettazione del progetto.

Quindi, qui, in questo schema, ho raggruppati i concetti di mostrare MVC all'interno di N-tier in una tipica applicazione monolitica. La comunicazione va da sinistra a destra e non passa sopra nessun altro livello (vedi: Architettura di cipolla). Nel livello di presentazione, il controller conosce il modello e la vista ma la vista e il modello non conoscono nulla per la maggior parte. Tuttavia, in molte versioni di MVC, tra cui ASP.Net e MVVM, la vista potrebbe conoscere l'interfaccia del modello o il prototipo (ma non l'istanza del modello) in modo che possa collegarsi ad esso.

Il controller gestirà la manipolazione del modello (o visualizza il modello in questo contesto), il che significa che potrebbe essere necessario conoscere l'oggetto dominio ei servizi di dominio. È possibile inserire facoltativamente un livello applicazione tra il livello di presentazione e il dominio se si desidera un'applicazione più riutilizzabile (ad esempio, l'applicazione potrebbe avere più teste: un'API Web e un'app desktop e un'app mobile, ecc.) Per fornire un confine transazionale e ulteriore isolamento. È importante che la vista non abbia alcuna conoscenza/dipendenza dagli oggetti di dominio in questa architettura: ecco perché esiste un modello separato per la vista. Il punto del modello in MVC è di creare un modello per la vista. Cioè, è un modello appositamente progettato per servire la vista, NON il dominio. Va bene che il modello di visualizzazione avvolga/adatta il modello di dominio a condizione che non venga mai esposto pubblicamente e/o accidentalmente serializzato.

In una nota a margine, il "livello di presentazione" in un'API Web, a mio parere, è il contratto serializzato (ad esempio JSON o XML). Quindi trattalo di conseguenza.

Answer 6

Proverò solo a rispondere alla domanda nel titolo. Quindi, qual è il ruolo di un controller in MVC?

Il lavoro deve essere un formato di modello per visualizzare il convertitore di formato in modo da non avere il modello guidato dall'interfaccia utente e la struttura del database guidata dall'interfaccia utente.

L'idea è di sviluppare la struttura del database basata sulla business logic e quindi sviluppare un'interfaccia utente indipendente. Ora, quando aggiungiamo o spostiamo alcuni controlli dell'interfaccia utente, la nostra struttura di modello e database non dovrebbe cambiare.