Domanda

Uso Kohana da un paio di mesi e sono ancora relativamente nuovo nello stile MVC nell'organizzazione del codice / presentazione / livello db. Sfortunatamente, sebbene ci sia molta documentazione su come creare un controller, stabilire una vista e interagire con un db tramite un modello, non ho trovato molte risorse che si occupano di modelli di sviluppo puliti e suggeriti.

Lasciami fare un rapido esempio:

Il mio ultimo progetto ha un controller, perché non sono sicuro se dovrei farne molti di più ... o quando dovrei crearne uno nuovo. Come faccio a determinare esattamente quando è necessario un nuovo controller, insieme a quando è necessario un nuovo modello?

È stato utile?

Soluzione

Ti consiglio di dare un'occhiata alla architettura orientata alle risorse , per prima cosa. Questo non ti fornirà linee guida dirette su come organizzare il tuo codice. Tuttavia, quando si pensa in termini di risorse, la vita è più facile quando si tratta di decidere se creare o meno un nuovo controller. Una volta che riesci a identificare una risorsa nel tuo sistema, di solito è una buona cosa creare un modello più un controller per esso - anche se, questa è solo una regola empirica.

Alcuni punti aggiuntivi:

  • cerca risorse e crea un modello e un controller per ciascuno di essi (regola empirica)
  • non aver paura di creare modelli per risorse che non persistono
  • pensa ai controller come " idraulico " oppure " cablaggio " degli utenti nel dominio aziendale - il loro ruolo è gestire le richieste degli utenti e inoltrare loro la risposta - mantenerle il più sottili possibile

Altri suggerimenti

Il pollice della regola è il seguente: quando identifico un nuovo tipo di " item " che la mia app. ho bisogno di gestire, mi pongo queste domande:

(1) Gli elementi di questo tipo devono essere persistenti?

(2) Ci saranno molte istanze di questo oggetto?

Se la risposta ad entrambe le domande è positiva, concludo che detto articolo dovrebbe essere un modello (o elemento-modello o classe di dominio, a seconda della terminologia del framework MVC). Quando definisco un nuovo elemento del modello, definisco anche un controller per esso che supporterà le quattro operazioni di base: creare, recuperare, aggiornare, eliminare (è probabile che il framework possa generare un controller predefinito per te).

Potresti voler ottenere una copia di "Patterns of Enterprise Application Architecture" di Martin Fowler. La sezione Presentazione Web illustra ampiamente come strutturare il codice quando si utilizza un framework guidato da Front Controller, come qualsiasi altra ondata di framework MVC.

Mi piacciono i piccoli controller con una funzione o un set di funzioni chiaramente definiti. Questo di solito significa un controller per pagina (o set di pagine simili). Nel mio sito Kohana, CSSMySite ho circa, blog, contatti, controller css e post.

Tutto ciò che fa il controller è impostare il modello. Il controller del blog interagisce con il modello del blog per elencare più post dal database. Il post controller interagisce con il modello blog per visualizzare un post dal database.

Ogni volta che ho dati persistenti (post di blog) o usati più volte (elenco di stati per una casella a discesa), vengono inseriti nel modello. È possibile accedere ai modelli da controller diversi, quindi non deve essere un mapping uno-a-uno del modello al controller.

Forse un buon modo per imparare una buona programmazione MVC è passare un po 'di tempo in Ruby-on-Rails. Ho iniziato a utilizzare le guide qualche tempo fa e, come risultato indiretto, credo di avere un'ottima conoscenza di MVC ora. Considero le rotaie come l'epitome di MVC. Almeno, potrebbe essere un modo divertente per imparare MVC ... cosa ne pensi?

Ecco un esempio di quello che ho fatto nella mia app Kohana.

Avevo bisogno di una sezione "ultime notizie", quindi ho impostato un controller, un modello e visualizzato il titolo "notizie".

Il mio controller di notizie aveva metodi index(), feed() e media_releases().

Il mio modello consisteva in query db che ottengono i miei dati di notizie da un database MySQL.

E la mia visione è solo un sacco di HTML con alcuni <?php echo $title; ?> e simili.

C'è un motivo per cui non è possibile definire un sistema generico che funzioni il metadata del database a livello globale? Mi sembra che generalmente scrivere qualsiasi codice per accedere e visualizzare dati semplici sia una ridondanza non necessaria.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top