controller vs. Modello - Necessità spiegazione

Question

Sono sull'inizio della mia strada "Impara MVC". Fondamentalmente, non ho grossi problemi con la programmazione orientata agli oggetti, ma c'è un aspetto tecnico che necessita di chiarimenti. Sembra che la mia teoria non sia abbastanza buona.

Attualmente, sto usando quadro KohanaPHP, versione 3.

situazione Esempio: Ho un sito web, dove l'utente può inviare un articolo.

così ho seguente struttura:

classes/ 
    /controllers/ 
     article.php 
    /models/ 
     articles.php 

Fin qui tutto bene. Non ho problemi con i modelli che estendono Kohana_Model, ma non sono sicuro se sto utilizzando il modo corretto i modelli che utilizzano ORM.

In sostanza quando si utilizzano modelli si estendono Kohana_Model Metterò tutte le operazioni logiche nel modello. Dovrei fare lo stesso per i modelli che usano ORM? In molti esempi sulla rete ho visto i controller che eseguivano operazioni logiche sull'input dell'utente/dati dal database che a mio parere non sono corretti.

Diciamo che ho bisogno di ottenere alcune righe dal database in modo creo metodo corretto nel modello e restituendo l'oggetto. Penso sia corretto, non è vero?

Fondamentalmente, tutte le operazioni di input dell'utente/dati (selezionare da db, inserire in db, convalida) metto nei modelli. Questo è il modo in cui comprendo il modello di progettazione MVC. I modelli dovrebbero fare attenzione a tutte le operazioni "meccaniche" e il controller è solo un "ponte" tra i modelli/viste ed è un motore "frontale".

E 'un approccio corretto?

So che potrebbe essere una domanda stupida per gli utenti più avanzati, tuttavia voglio imparare solo le buone pratiche. Se qualcuno potesse fornire qualche chiarimento, ne sarei felice.

Answer 1

in tempi brevi, il vostro modello esegue tutte le operazioni sui dati (sia in entrata, in uscita, database, file ... dati) e la tua vista dovrebbe occuparsi della visualizzazione dei dati. Il controller dovrebbe chiamare i metodi di modello necessari per ottenere i dati pronti per essere passati alla vista. Il controller non dovrebbe apportare modifiche ai dati, ma dovrebbe testarlo per ottenere l'azione necessaria eseguita correttamente.

Spero di averlo chiarito abbastanza, fammi sapere se questo non chiarisce le cose per te.

Answer 2

Non ho lavorato con KohanaPHP ma sembra un framework 'rails-inspired'. Nel mondo rotaie è generalmente considerato migliori pratiche per avere controllori magro e modelli di grasso.

alcuni retroscena può essere trovato in questo vecchio articolo di Jamis scaricabarile http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model o in questo quella relativa cakephp http://gluei.com/blog/view/cakephp-best-practices-fat-models-and-skinny-controllers

Answer 3

L'idea di separare la logica dai dati è che i dati non contengono la logica, quindi nei vostri modelli si dovrebbero solo sanare i dati.

Prendete questo esempio:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id = false) 
    { 
     if(!$user_id) 
     { 
      $user_id = get_guest_id(); 
     } 
     //Insert 
    } 
} 

Sembra logica legittima nei modelli, ma da ora in poi l'applicazione deve essere in grado di consentire agli ospiti di pubblicare articoli, o la sua viziata e è necessario modificare i modelli, che poi pavimento volontà le altre applicazioni/aree del sito

Prendere questo scenario:

Hai 2 siti

• ComputerArticles.com
• CookingArticles.com

Ora questi 2 domini puntano allo stesso server, ma un'applicazione separata in Kohona, da non porre alcuna logica di dominio con i tuoi modelli tuo grado di utilizzare i modelli esatti di esempio attraverso tutti i tuoi domini.

I suoi metodi di modello dovrebbe apparire in questo modo:

public class Articles extends MasterModelLayer 
{ 
    public function create($title,$text,$user_id) 
    { 
     $this->compile("articles",array($title,$text,$user_id))->insert(); 
    } 
} 

e nel rispetto del controller si dovrebbe mettere tutti la logica della logica dipende dal dominio.

Pensa ai tuoi modelli come API, in cui hai più siti che utilizzano la stessa API ma con logica diversa.

Spero che questo aiuti.

Answer 4

Qui ci sono le definizioni di laico di base dei termini - Viste: Gli schermi presentati agli utenti controller: Un motore/quadro che prende nelle richieste, determina chi gestisce e li delegati modo appropriato. Modello: Questo in pratica ti dice quale schermata mostrare dopo così e così l'azione viene eseguita su questo schermo. Pensalo come un grafico (diretto). I bordi che emergono da un nodo sono azioni e i nodi a cui si collegano sono le prossime schermate basate su quelle azioni.

Quindi un modello in pratica include le azioni eseguite dagli utenti sugli schermi e i relativi gestori di azioni. Il controllore chiama semplicemente un gestore di azioni corrispondente per una particolare azione dell'utente e il gestore di azioni è responsabile di fare qualcosa di ragionevole con la richiesta in arrivo.

Ora la tua domanda. Dove va la logica aziendale? Bene, è il gestore di azioni. O è astratto da qualche parte la gente ama chiamare - strato di affari. Ma comunque è innescato fuori dagli stessi handler di azione.

Quindi, tecnicamente, la logica aziendale è parte di azioni che sono esse stesse parte del Modello. Questo ha senso se lo si pensa in questo modo: il controller gestisce l'interazione dell'utente e presenta viste basate sul modello (azioni + attività).

** Errori di battitura corretti.