In Rails, non dovremmo creare un livello di servizio, invece della logica jumbling in un controller?

Question

Dire che ho un controller che restituisce un elenco di utenti. Gli utenti devono essere restituiti da memcache se la chiave cache esiste, altrimenti si preme mysql db. Questa logica verrà riutilizzata per dire un livello di servizio web o qualcosa del genere.

azione:

def list 

    if in cache 
    @userlist = ... 
    else 
    @userlist = User.all() 
    end 

end 

Nel mondo Java, si creerebbe uno strato UserService che avvolgere logica addizionale (come prima verifica del livello della cache, ecc).

In rotaie le persone tendono a mettere tutta questa logica nel controller.

Qual è la migliore pratica di Rails qui?

Answer 1

Il "modo Rails" è: controller skinny, modelli di grasso.

Si può semplicemente cambiare il modello a supporto della cache:

class User < ActiveRecord::Base 
    def self.all 
    @cached[:all] ||= super 
    end 
end 

o creare un iniettore per sostenere la cache nel modo desiderato per più modelli:

class User < ActiveRecord::Base 
    include CacheInjector 
end 

Ricorda: Ruby, come una dinamica linguaggio, è molto facile da estendere. Mixin, intercettatori, aspetti, tutte quelle cose che sono PITA da implementare in Java, sono molto semplici e naturali su Ruby. Provaci.

Answer 2

Perché non eseguire tale controllo nel modello e chiamare semplicemente una funzione modello dal controller. Modelli grassi e controller skinny

Answer 3

Sembra esserci un movimento "piccolo" nella comunità di Rails per stabilire un livello di servizio in alcuni progetti/applicazioni. Nel 2010, ho lavorato a un progetto in cui abbiamo introdotto una directory app/servizi per archiviare oggetti di servizio. Abbiamo scoperto che la logica dell'applicazione era distribuita su controller e modelli e questo ha contribuito a incapsulare questo comportamento. James Golick ha un post interessante sull'argomento. Scopri i commenti di Pat Maddox così:

http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html

Answer 4

Ora giorni ci sono più punti di vista su questo argomento, ad esempio:

http://blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/

http://rubysource.com/ddd-for-rails-developers-part-1-layered-architecture/

Il mio consiglio di default è di segui i principi OOP, semplifica le cose, non violare l'SRP e creare astrazioni significative.