Modello, vista, controller e helper di Rails:cosa va dove?

Question

In Ruby on Rails Development (o MVC in generale), quale regola rapida dovrei seguire su dove inserire la logica.

Si prega di rispondere affermativamente - Con Metti questo qui, piuttosto che Non metterlo lì.

Answer 1

MVC

Controllore:Inserisci qui il codice che ha a che fare con l'elaborazione di ciò che un utente desidera e la decisione di cosa dargli, la determinazione se ha effettuato l'accesso, se deve vedere determinati dati, ecc.Alla fine, il controller esamina le richieste e stabilisce quali dati (modelli) mostrare e quali visualizzazioni rendere.Se hai dei dubbi se il codice debba essere inserito nel controller, probabilmente non dovrebbe.Mantieni i tuoi controller magro.

Visualizzazione:La vista dovrebbe contenere solo il codice minimo per visualizzare i tuoi dati (Modello), non dovrebbe fare molte elaborazioni o calcoli, dovrebbe visualizzare dati calcolati (o riepilogati) dal Modello o generati dal Controller.Se la tua vista ha davvero bisogno di eseguire un'elaborazione che non può essere eseguita dal modello o dal controller, inserisci il codice in un Helper.Molto codice Ruby in una vista rende difficile la lettura del markup delle pagine.

Modello:Il tuo modello dovrebbe essere dove Tutto il tuo codice relativo ai tuoi dati (le entità che compongono il tuo sito, ad es.Utenti, Post, Account, Amici ecc.) vive.Se il codice deve salvare, aggiornare o riepilogare i dati relativi alle tue entità, inseriscilo qui.Sarà riutilizzabile su visualizzazioni e controller.

Answer 2

Per aggiungere alla risposta di pauliephonic:

Aiutante:funzioni per facilitare la creazione della vista.Ad esempio, se esegui sempre l'iterazione su un elenco di widget per visualizzarne il prezzo, inseriscilo in un helper (insieme a un partial per la visualizzazione effettiva).Oppure, se hai un pezzo di RJS che non vuoi ingombrare la vista, inseriscilo in un aiutante.

Answer 3

Il modello MVC riguarda in realtà solo l'interfaccia utente e nient'altro.Non dovresti inserire alcuna logica aziendale complessa nel controller poiché controlla la vista ma non la logica.Il controller dovrebbe preoccuparsi di selezionare la vista corretta e delegare elementi più complessi al modello di dominio (modello) o al livello aziendale.

Domain Driven Design ha un concetto di servizi che è un luogo in cui si attacca la logica che deve orchestrare una serie di vari tipi di oggetti che generalmente significa logica che non appartiene naturalmente a una classe modello.

Generalmente penso al livello di servizio come all'API delle mie applicazioni.I livelli dei miei servizi di solito si adattano abbastanza fedelmente ai requisiti dell'applicazione che sto creando, quindi il livello del servizio agisce come una semplificazione delle interazioni più complesse che si trovano nei livelli inferiori della mia app, ad es.potresti raggiungere lo stesso obiettivo ignorando i livelli di servizio ma dovresti usare molte più leve per farlo funzionare.

Nota che non sto parlando di Rails qui, sto parlando di uno stile architettonico generale che affronta il tuo problema particolare.

Answer 4

Spiegazioni perfette già qui, una frase molto semplice come conclusione e facile da ricordare:

Abbiamo bisogno di modelli SMART, controller THIN e visualizzazioni DUMB.

http://c2.com/cgi/wiki?ModelViewController

Answer 5

Il metodo Rails è avere controller magri e modelli grassi.

Answer 6

Inserisci elementi relativi all'autorizzazione/controllo dell'accesso nel controller.

I modelli riguardano tutti i tuoi dati.Validazione, Relazioni, CRUD, Logica di Business

Le visualizzazioni riguardano la visualizzazione dei tuoi dati.Visualizzazione e acquisizione solo di input.

I controller servono a controllare quali dati vanno dal tuo modello alla tua vista (e quale vista) e dalla tua vista al tuo modello.I controllori possono esistere anche senza modelli.

Mi piace pensare al controller come a una guardia di sicurezza/receptionist che indirizza il cliente (richiesta) allo sportello appropriato dove fai una domanda a un cassiere (visualizza).Il cassiere (vista) poi va a ricevere la risposta da un manager (modello), che non vedi mai.Dopo aver effettuato la richiesta, torna dalla guardia di sicurezza/receptionist (controllore) e attendi finché non ti verrà indirizzato a un altro cassiere (vedi) che ti dirà la risposta che il manager (modello) ha dato loro in risposta alla domanda dell'altro cassiere (vedi) .

Allo stesso modo, se vuoi dire qualcosa al cassiere (visualizzare), allora accade in gran parte la stessa cosa, tranne che il secondo cassiere ti dirà se il manager ha accettato le tue informazioni.È anche possibile che la guardia di sicurezza/addetto alla reception (controllore) ti abbia detto di fare un'escursione poiché non eri autorizzato a fornire tale informazione al gestore.

Quindi, per estendere la metafora, nel mio mondo stereotipato e irrealistico, i cassieri (o punti di vista) sono carini ma con la testa vuota e spesso credono a tutto ciò che dici loro, le guardie di sicurezza/receptionist sono minimamente educati ma non sono molto ben informati ma sanno dove le persone dovrebbero e non dovrebbe andare e i manager sono davvero brutti e cattivi ma sanno tutto e sanno dire cosa è vero e cosa non lo è.

Answer 7

Una cosa che aiuta a separarsi correttamente è evitare l'anti-pattern "passa variabili locali dal controller alla vista".Invece di questo:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

Prova a spostarlo su un getter disponibile come metodo di supporto:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

Ciò semplifica la modifica di ciò che viene inserito in "@foo" e di come viene utilizzato.Aumenta la separazione tra controller e visualizzazione senza renderli più complicati.

Answer 8

Beh, dipende un po' da cosa ha a che fare la logica...

Spesso ha senso inserire più elementi nei propri modelli, lasciando i controller piccoli.Ciò garantisce che questa logica possa essere facilmente utilizzata da qualsiasi luogo sia necessario accedere ai dati rappresentati dal modello.Le visualizzazioni non dovrebbero contenere quasi alcuna logica.Quindi, in generale, dovresti sforzarti di fare in modo di non ripeterti.

Inoltre, una veloce ricerca su Google rivela alcuni esempi più concreti di cosa va dove.

Modello:requisiti di validazione, relazioni tra dati, creazione di metodi, aggiornamento di metodi, distruzione di metodi, ricerca di metodi (nota che non dovresti avere solo le versioni generiche di questi metodi, ma se c'è qualcosa che fai spesso, come trovare persone con i capelli rossi tramite cognome, allora dovresti estrarre quella logica in modo che tutto ciò che devi fare sia chiamare find_redH_by_name("smith") o qualcosa del genere)

Visualizzazione:Dovrebbe riguardare la formattazione dei dati, non l'elaborazione dei dati.

Controllore:È qui che va l'elaborazione dei dati.Da Internet:"Lo scopo del responsabile del trattamento è rispondere all'azione richiesta dall'utente, acquisire tutti i parametri impostati dall'utente, elaborare i dati, interagire con il modello e quindi trasmettere i dati richiesti, in forma finale, alla visualizzazione."

Spero che aiuti.

Answer 9

In termini semplici, in generale,Modelli avrà tutti i codici relativi alle tabelle, le loro relazioni semplici o complesse (pensale come query SQL che coinvolgono più tabelle), la manipolazione dei dati/variabili per arrivare a un risultato utilizzando la logica aziendale.

Controllori avrà codici/indicatori verso i modelli rilevanti per il lavoro richiesto.

Visualizzazioni accetterà l'input/l'interazione dell'utente e visualizzerà la risposta risultante.

Qualsiasi deviazione importante da questi sottoporrà a sforzo indesiderato quella parte e le prestazioni complessive dell'applicazione potrebbero risentirne.

Answer 10

Testare, testare...Inserisci quanta più logica possibile nel modello e sarai in grado di testarlo correttamente.I test unitari testano i dati e il modo in cui sono formati testando il modello, mentre i test funzionali testano il modo in cui vengono instradati o controllati testando i controller, quindi ne consegue che non è possibile testare l'integrità dei dati a meno che non siano in il modello.

J