Capire MVC: Che cosa è il concetto di “Fat” sui modelli, “skinny” sui controller?

Question

Sto cercando di capire il concetto di "Fat" sui modelli vs "skinny" sui controller e da quello che ho discusso Ho il seguente esempio (questo è preso da una discussione freenode):

D: Su MVC paradigma, i suoi detti modelli Fat, controllori magro. Sto qui a pensare, se ho un sacco di metodi (su Controller) che utilizza solo pochi metodi astratti a CRUD (il modello), Sto creando un controller grassi invece di un modello? Oppure dicono, il modello di grasso, refearing in quello che viene restituito e non digitato? Questo è qualcosa che non ho mai capito =) Eventuali commenti sono apprezzati! Grazie mille

OBS1: non sto facendo che cosa è ment dal modello, nel controller, devo solo metodi che cosa è il controllo che vanno al modello

OBS2: SAY let "checkIfEmailExists ()", ha "john@hotmail.com", come parametri di. Questo metodo, ottenere il ritorno dal metodo modello che querys se questo esiste param nella tabella, ritorno booleano. Se è 0, "checkIFemailExists ()" chiamerà un metodo modello di spettacolo diverso, questo, lui è solo un altro metodo astratto, che l'operazione esegue Update.

OBS3: I "checkIfEmailExists ()", isnt solo un controllore? Non sta in realtà eseguire qualsiasi CRUD, sta solo confrontando i valori ecc Ecco che cosa mi confonde, perché nella mia testa questo è un controller: S

Note: Credo che questo non è l'esempio migliore, dal momento che dice "di controllo se qualcosa esiste", suona come una query mia operazione tabella

Q2: Ancora una domanda, quindi, diciamo che ho un modulo di vista, da dove tale parametro indirizzo di posta elettronica viene inviato da. Stai dicendo che la vista va direttamente al modello?

Q3: nel caso non l'atto di controllo tra di loro? questo è il paradigma

Nota finale: La discussione è conclusa, dicendo che ho sbagliato, desiderio è ok (sto imparando). Ma, così, che cosa le risposte giuste per Q2 e Q3?

Grazie per l'attenzione alle targhe

Answer 1

L'applicazione non è il M. Essa dovrebbe essere in grado di stare indipendente dalla V e C. V e C costituiscono l'interfaccia utente per l'applicazione. Se questa è un'interfaccia web o di un'interfaccia a riga di comando non dovrebbe importa per la logica core business della vostra applicazione per l'esecuzione. Si desidera che il modello sia il grasso con la logica di business.

Se si dispone di un controller di grassi, invece, ad esempio, completa con la logica di business, non si sta aderendo alla scopo di MVC. esclusiva responsabilità di un controllore sta gestendo e delegando le richieste dell'interfaccia utente del Modello. Ecco perché dovrebbe essere magro. Esso deve contenere solo codice necessario per quello che è responsabile.

semplificato Esempio

public function fooAction()
{
    if(isset($_POST['bar'])) {
        $bar = Sanitizer::sanitize($_POST['bar']);
        $rows = $this->database->query('SELECT * from table');
        try {
            foreach($rows as $row) {
                $row->foo = $bar;
                $row->save();
            }
        } catch (Exception $e) {
            $this->render('errorPage');
            exit;
        }
        $this->render('successPage');
    } else {
        $this->render('fooPage');
    }
}

Quando si deve essere

public function fooAction()
{
    if(isset($_POST['bar'])) {
        $success = $this->tableGateway->updateFoo($_GET['bar']);
        $page    = $success ? 'successPage' : 'errorPage';
        $this->render($page);
    } else {
        $this->render('fooPage');
    }
}

perché è tutto il controllore ha bisogno di sapere. Non deve aggiornare le righe. Si deve solo dire al modello che qualcuno ha richiesto questo cambiamento. L'aggiornamento è di responsabilità della classe dirigente le righe. Inoltre, il controllore non deve necessariamente disinfettare il valore.

Per quanto riguarda la Q2 e Q3, si prega di vedere la mia risposta a Posso chiamare un modello dalla vista .

Answer 2

Ho lavorato con MVC paradigma per molto tempo e posso condividere con voi la mia esperienza.

La parte "modello" è responsabile della gestione di tutte le cose che non è strettamente "web", come la convalida, la logica, l'accesso ai dati, ecc Pensate a come una sorta di strato di business misto + strato di accesso ai dati. Si può anche avere BLL + DAL in assemblee separate e utilizzare la parte "modello" di MVC come un ponte tra il BLL e la tua App, più l'aggiunta di classi che sono specifici per l'applicazione MVC e non legati alla BLL, come le classi Viewdata , ecc.

La parte "controllore" è quello che si prende cura delle cose web specifico, come l'autenticazione, biscotti, GET e POST, querystrings, ecc Esso utilizza la roba presente nel modello e / o il BLL e invia i dati che sono essere reso all'utente i punti di vista.

Le "viste" sono i tuoi modelli HTML che possono ricevere i dati dal controller, e visualizzarlo. Nessuna operazione logica dovrebbe mai essere fatto in vista, quindi non "se" dichiarazioni, nessun cicli, ecc Se vi trovate a dover tali necessità, allora avete bisogno di alcuni metodi di "helper" che creano il codice HTML desiderato e poi li chiamano dalla vista. Quindi, viste ricevono solo i dati, e di offrire ai collegamenti degli utenti / moduli per inviare i dati ad un controllore, ma non lo fanno elaborato nulla.

Spero che questo cancellato alcuni dei vostri dubbi.

Answer 3

Ho sempre interpretato che per significare che i modelli dovrebbero incapsulare la logica relativa a quei modelli in un approccio più orientato agli oggetti, invece di avere tutta la logica nei controllori in un approccio più procedurale. Per citare La cattedrale e il bazaar :

  

Smart strutture di dati e il codice muto lavora molto meglio rispetto al contrario.

Answer 4

I può mostrare un mio pregiudizio (verso C #), ma non credo abbia molto senso parlare di MVC a meno che non si sta utilizzando uno stile di programmazione orientata agli oggetti. Un controllore non è un metodo, è un insieme di metodi raggruppati in una classe, ognuno dei quali gestisce un certo input (url / richiesta). Un modello non è un modo di accesso al database (che è uno strato di accesso ai dati), è un insieme di proprietà e metodi che incapsulano qualche entità identificabile nella vostra applicazione: una persona, una prenotazione, un prodotto, ecc Il modo migliore per pensare a questo proposito è che l'ingresso controller maniglia, modelli contengono i dati -., ma, naturalmente, che è semplificato

La questione del "Fat" vs "skinny", per me, è la questione di dove finisce la logica di business dal vivo. Se hai un sacco di logica nel vostro controller legate, non solo la gestione dell'input, ma implementare la logica di business, quindi i vostri controller sono relativamente più grasso che se li si usa semplicemente di tradurre le richieste in assemblaggi di modelli che sono passata ad una vista a rendere . Nella mia esperienza, non è sempre un o / o una decisione. Un sacco di tempo che avete logica di business (convalida, rapporto di manutenzione, revisione contabile) nel modello, mentre si dispone logica applicativa (convalida il permesso, sanificazione, etc.) nel controller, anche.

Answer 5

Credo che una separazione di controllo buona / modello potrebbe essere fatta lasciando regolatore di fare "sintattici" operazioni dipendenti con nessuna logica / poche imprese coinvolte e l'uso del modello per eseguire le operazioni correlate "semantici".

Un buon esempio di tale separazione è:

È possibile eseguire il controllo regexp di una e-mail nel controller, ma non si esibirà LDAP corrispondenza di quella e-mail nel controller.