Quando creare un nuovo controller nei binari

Question

Mi chiedo quando si sa che è necessario creare un controller in un'applicazione rails.

Ad esempio, sto seguendo il tutorial in Agile Web Development con Rails e l'applicazione crea diversi modelli, tutti con viste e contollers separati. Tuttavia, creiamo anche un controller Store, ma nessun modello ad esso associato. Perché abbiamo bisogno di un controller senza modello? I controller per i modelli non potrebbero gestire tutte le operazioni necessarie?

È comune? Se sì, come si determina quando qualcosa garantisce un controller?

Grazie!

---

Queste risposte aiutano, grazie.

La mia preoccupazione è che quando svilupperò qualcosa per conto mio, inizierò a creare controller inutili, o dall'altra parte, non creeremo controller necessari. Ma, suppongo, devo smettere di pensare a controller e modelli come una relazione 1-1, corretto? Se sto capendo correttamente, potrebbero esserci molti controller che accedono a un modello e molti modelli utilizzati in un controller?

Answer 1

UPDATE: Consiglio vivamente di leggere How DHH Organizes His Rails Controllers che praticamente lo spiega molto meglio della mia risposta originale.

---

Credo che la questione sarebbe più adatto se si desidera metterla in un altro modo:

Perché abbiamo bisogno di modello (AR in questo caso) per ogni controller?

E la risposta ovviamente è che non lo fai. Quando pensi ai controller, è meglio non pensare ai dati, ma fai un piccolo passo indietro e pensa alle risorse . Se cerchi REST in Internet, troverai molti articoli e molti di essi includeranno varie spiegazioni dei termini risorsa e rappresentazione. Per farla breve, limitiamoci a semplificare e diciamo che la risorsa è tutto ciò che vale la pena menzionare. Gli articoli sono una risorsa (raccolta). Store è una risorsa (singolare, membro).

Ad esempio, per accedere agli utenti. Probabilmente hai già UsersController che (di default) ti permetterà di aggiungere nuovi utenti (creare risorse), eliminarli (rimuovere risorse), visualizzare utenti singoli e anche tutti gli utenti. Se pensi solo in termini di dati e controller, probabilmente inizieresti a creare azioni aggiuntive come login_user in UserController, che è un odore. Se pensi alle risorse, e questo è "tutto ciò che vale la pena menzionare o creare URI per questo", potresti pensare che hai bisogno di un'altra risorsa, e cioè: sessioni. Pensa in questo modo: quando l'utente esegue l'accesso, in realtà crea una risorsa di sessione. E con la disconnessione, si elimina, rimuovere la risorsa. E 'molto meglio spiegato nel tutorial libro Rails che raccomando: http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions

Per ricapitolare, questo può aiutare a capire quando è necessario nuovo controller:

• Quando si pensa di mettere non RESTful azioni in controller come log_in, calculate_date, ecc.
• Quando c'è qualcosa che puoi nominare e che è "abbastanza interessante" da essere una risorsa separata.
• Inoltre, quando si sviluppa in "fuori in" stile, tali risposte arrivano in modo più naturale: http://rubylearning.com/blog/2010/10/05/outside-in-development/

Nel complesso, conoscere REST e la sua filosofia aiuterà molto.

Answer 2

Un controller può essere utilizzato per creare pagine senza limiti di un modello. Un esempio potrebbe essere un avviso legale o sth. come quello. Materiale statico, ...

A Controller dati di controllo. Nella maggior parte dei casi questi dati provengono dal Model ma questo non è necassary wheater è la combinazione più comune.

Answer 3

Ovviamente, non esiste una regola rigida; ma penso che sia utile pensare in termini di ciò che le tre diverse parti del MVC rappresentano (o "sì"):

• modelle rappresentano i dati e back-end dei dati, la logica
• controllori lasciare che il all'utente di interagire con i modelli
• Visualizzazioni sono ciò che l'utente vede quando l'utente interagisce tramite un controller

Così diversi cont i rulli verrebbero usati per quando si desidera che faccia cose diverse (categorie di).

Ad esempio, nel libro AWD, l'applicazione Depot funziona (in senso lato) manipolando e memorizzando i prodotti, quindi ha un modello di prodotto.

Esistono due modi distinti di interazione; come proprietario del deposito (aggiunta di prodotti, adeguamento dei prezzi e dello stock ...) o come cliente (aggiunta di prodotti al carrello, controllo ...). Quindi ha un controller Admin per il primo e un controller Store per quest'ultimo.

Un altro motivo, e che spesso si lega al primo, è se i controller hanno bisogno di un involucro diverso. Ad esempio, è necessario autenticare l'utente prima di eseguire qualsiasi roba di amministrazione, ma non per le cose basate sul cliente. Quindi puoi separare le azioni in due controller e mettere uno before_filter su Admin per gestire l'autenticazione.

Answer 4

Sono anche nuovo di RoR e sto facendo un tutorial di Michael Hartl. Ho trovato nella mia ricerca e parlando con Rubyist più esperto che quando hai bisogno dell'aiuto del tuo modello (database) dovresti creare un controller. Ad esempio, se si sta creando una sessione e il metodo che si sta creando avrà bisogno di interfacciarsi con il modello (database) utilizzando, memorizzando, aggiornando, aggiungendo (a.k.a. comportamento RESTful), allora sarà necessario un controller.

Perché? Come detto prima: il lavoro del telaio MVC richiede che i Controller siano l'unico elemento in grado di interagire con i Modelli (un po 'come un buttafuori nella sezione VIP di un night club pieno di donne bollenti! I geek sono rappresentati da "the view" LOL! !) !!