OO Design in Rails: dove mettere le cose

Mi sto davvero divertendo con Rails (anche se in genere sono RESTless) e mi piace che Ruby sia molto OO. Tuttavia, la tendenza a creare enormi sottoclassi ActiveRecord e enormi controller è abbastanza naturale (anche se si utilizza un controller per risorsa). Se dovessi creare mondi di oggetti più profondi, dove metteresti le classi (e i moduli, suppongo)? Sto chiedendo informazioni su (negli Helpers stessi?), Controller e modelli.

Lib è a posto, e ho trovato alcune soluzioni per farlo ricaricare in un ambiente di sviluppo , ma mi piacerebbe sapere se c'è un modo migliore per fare queste cose. Sono davvero preoccupato solo per le classi che stanno diventando troppo grandi. Inoltre, che dire dei motori e come si adattano?

Poiché Rails fornisce una struttura in termini di MVC, è naturale finire per utilizzare solo i contenitori di modelli, viste e controller forniti. Il linguaggio tipico per i principianti (e anche per alcuni programmatori intermedi) è stipare tutta la logica nell'app nel modello (classe di database), controller o vista.

A un certo punto, qualcuno sottolinea il paradigma "modello grasso, controllore scarno" e gli sviluppatori intermedi escono in fretta tutto dai loro controller e lo gettano nel modello, che inizia a diventare un nuovo cestino per la logica dell'applicazione.

I controller skinny sono, in effetti, una buona idea, ma il corollario - mettere tutto nel modello, non è proprio il piano migliore.

In Ruby hai un paio di buone opzioni per rendere le cose più modulari. Una risposta abbastanza popolare è usare solo i moduli (di solito nascosti lib) che contengono gruppi di metodi e quindi includere i moduli nelle classi appropriate. Questo aiuta nei casi in cui si hanno categorie di funzionalità che si desidera riutilizzare in più classi, ma in cui la funzionalità è ancora teoricamente collegata alle classi.

Ricorda, quando includi un modulo in una classe, i metodi diventano metodi di istanza della classe, quindi finisci con una classe che contiene una tonnellata di metodi, sono semplicemente organizzati in modo semplice in più file.

Questa soluzione può funzionare bene in alcuni casi - in altri casi, vorrai pensare all'utilizzo di classi nel tuo codice che non siano modelli, viste o controller.

Un buon modo di pensarci è il "principio della singola responsabilità", secondo il quale una classe dovrebbe essere responsabile di un singolo (o piccolo numero) di cose. I tuoi modelli sono responsabili della persistenza dei dati dalla tua applicazione al database. I responsabili del trattamento sono responsabili della ricezione di una richiesta e della restituzione di una risposta valida.

Se si dispone di concetti che non rientrano esattamente in quelle scatole (persistenza, richiesta / risposta di gestione), probabilmente avrete bisogno di pensare a come si potrebbe modellare l'idea in questione. Puoi archiviare classi non modello in app / classi o in qualsiasi altro luogo e aggiungere quella directory al percorso di caricamento effettuando:

config.load_paths << File.join(Rails.root, "app", "classes")

Se stai usando passeggero o JRuby, probabilmente vorrai anche aggiungere il tuo percorso ai percorsi di carico desiderosi:

config.eager_load_paths << File.join(Rails.root, "app", "classes")

La linea di fondo è che una volta arrivato a Rails in cui ti trovi a porre questa domanda, è tempo di rinforzare le tue costolette di Ruby e iniziare a modellare le classi che non sono solo le classi MVC che Rails ti offre di default.

Aggiornamento: questa risposta si applica a Rails 2.xe versioni successive.

Aggiornamento : l'uso di Preoccupazioni è stato confermato come la nuova impostazione predefinita in Rails 4 .

Dipende molto dalla natura del modulo stesso. Di solito inserisco le estensioni del controller / modello in una cartella / concernente l'app.

# concerns/authentication.rb
module Authentication
  ...
end    

# controllers/application_controller.rb
class ApplicationController
  include Authentication
end



# concerns/configurable.rb
module Configurable
  ...
end    

class Model 
  include Indexable
end 

# controllers/foo_controller.rb
class FooController < ApplicationController
  include Indexable
end

# controllers/bar_controller.rb
class BarController < ApplicationController
  include Indexable
end

/ lib è la mia scelta preferita per le librerie di uso generale. Ho sempre uno spazio dei nomi di progetto in lib in cui inserisco tutte le librerie specifiche dell'applicazione.

/lib/myapp.rb
module MyApp
  VERSION = ...
end

/lib/myapp/CacheKey.rb
/lib/myapp/somecustomlib.rb

Le estensioni core di Ruby / Rails di solito hanno luogo negli inizializzatori di configurazione in modo che le librerie vengano caricate una sola volta sul boostrap di Rails.

/config/initializer/config.rb
/config/initializer/core_ext/string.rb
/config/initializer/core_ext/array.rb

Per frammenti di codice riutilizzabili, creo spesso plug-in (micro) in modo da poterli riutilizzare in altri progetti.

I file helper di solito contengono metodi helper e talvolta classi quando l'oggetto è destinato ad essere utilizzato dagli helper (ad esempio Form Builders).

Questa è una panoramica davvero generale. Fornisci maggiori dettagli su esempi specifici se desideri ottenere suggerimenti più personalizzati. :)

... la tendenza a creare enormi sottoclassi ActiveRecord e enormi controller è abbastanza naturale ...

"enorme" è una parola preoccupante ... ;-)

In che modo i tuoi controller stanno diventando enormi? È qualcosa che dovresti guardare: idealmente, i controller dovrebbero essere magri. Scegliendo una regola empirica dal nulla, suggerirei che se hai regolarmente più di, per esempio, 5 o 6 righe di codice per metodo del controller (azione), probabilmente i tuoi controller sono troppo grassi. Esistono duplicazioni che potrebbero spostarsi in una funzione di supporto o in un filtro? Esiste una logica aziendale che potrebbe essere inserita nei modelli?

In che modo i tuoi modelli diventano enormi? Dovresti cercare modi per ridurre il numero di responsabilità in ogni classe? Ci sono comportamenti comuni che puoi estrarre nei mixin? O aree di funzionalità che è possibile delegare alle classi di supporto?

EDIT: Cercando di espandersi un po ', speriamo di non distorcere qualcosa di troppo male ...

Aiutanti: vivono app/helperse sono principalmente utilizzati per semplificare le visualizzazioni. Sono specifici del controller (disponibili anche per tutte le visualizzazioni per quel controller) o generalmente disponibili ( module ApplicationHelperin application_helper.rb).

Filtri: supponi di avere la stessa riga di codice in diverse azioni (abbastanza spesso, recupero di un oggetto usando params[:id]o simili). Tale duplicazione può essere prima astratta in un metodo separato e poi completamente fuori dalle azioni dichiarando un filtro nella definizione della classe, ad esempio before_filter :get_object. Vedere la sezione 6 della Guida alle rotaie di ActionController. Lascia che la programmazione dichiarativa sia tua amica.

I modelli di refactoring sono un po 'più una cosa religiosa. I discepoli di zio Bob suggeriranno, ad esempio, di seguire i cinque comandamenti di SOLID . Joel & Jeff possono raccomandare un approccio più "pragmatico", anche se in seguito sembravano essere un po 'più riconciliati . Trovare uno o più metodi all'interno di una classe che operano su un sottoinsieme chiaramente definito dei suoi attributi è un modo per provare a identificare le classi che potrebbero essere rifattorizzate dal modello derivato da ActiveRecord.

A proposito, i modelli Rails non devono essere sottoclassi di ActiveRecord :: Base. O, per dirla in altro modo, un modello non deve essere un analogo di una tabella, o addirittura correlato a qualcosa memorizzato. Ancora meglio, fintanto che app/modelsassegni il tuo file secondo le convenzioni di Rails (chiama #underscore sul nome della classe per scoprire cosa cercherà Rails), Rails lo troverà senza requireche sia necessario.

Ecco un eccellente post sul blog sul refactoring dei modelli di grasso che sembrano derivare dalla filosofia del "controller sottile":

http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

Il messaggio di base è "Non estrarre mixin da modelli fat", utilizzare invece le classi di servizio, l'autore fornisce 7 modelli per farlo