Migliori pratiche per la progettazione di modelli in Ruby on Rails

Question

I tutorial RoR presuppongono un modello per tabella affinché l'ORM funzioni.Il mio schema DB ha circa 70 tabelle divise concettualmente in 5 gruppi di funzionalità (ad esempio, ogni data tabella vive in un solo gruppo funzionale e sono minimizzate le relazioni tra tabelle di diversi gruppi.) Quindi:dovrei progettare un modello per gruppo concettuale o dovrei semplicemente avere 70 modelli Rails e lasciare il raggruppamento "concettuale"?Grazie!

Answer 1

Ne parlo in una delle mie app di grandi dimensioni assicurandomi semplicemente che le tabelle/modelli siano concettualmente raggruppati per nome (con una relazione tabella-modello quasi 1:1).Esempio:

events
event_types
event_groups
event_attendees
etc...

In questo modo, quando utilizzo TextMate o altro, i file del modello sono ben raggruppati insieme in base all'ordinamento alfa.Ho 80 modelli in questa app e funziona abbastanza bene da mantenere le cose organizzate.

Answer 2

Molto probabilmente, dovresti avere 70 modelli.Potresti assegnare uno spazio ai nomi ai modelli per avere 5 spazi dei nomi, uno per ciascun gruppo, ma ciò può essere più un problema che un valore.Più probabilmente, hai alcune funzionalità comuni a ciascun gruppo.In tal caso, creerei un modulo per ciascun gruppo contenente il suo comportamento e lo includerei in ciascun modello pertinente.Anche se non sono presenti funzionalità condivise, questa operazione può consentire di eseguire rapidamente query su un modello per il relativo gruppo concettuale.

Answer 3

Dovresti assolutamente utilizzare un modello per tabella per sfruttare tutta la magia di ActiveRecord.

Ma potresti anche raggruppare i tuoi modelli in spazi dei nomi utilizzando moduli e sottodirectory, per evitare di dover gestire 70 file nella directory dei modelli.

Ad esempio, potresti avere:

app/models/admin/user.rb
app/models/admin/group.rb

per i modelli Admin::Utente e Admin::Gruppo e

app/models/publishing/article.rb
app/models/publishing/comment.rb

per Pubblicazione::Articolo e Pubblicazione::Commento

E così via...

Answer 4

Senza conoscere maggiori dettagli sulla natura delle settanta tavole e sulle loro relazioni concettuali non è proprio possibile dare una buona risposta.Si tratta di tabelle legacy o le hai progettate da zero?

Le tabelle sono correlate da qualche tipo di modello di ereditarietà o potrebbero esserlo?Rails può eseguire una forma limitata di ereditarietà.Cerca Eredità della tabella singola (STI).

Personalmente, farei molti sforzi per evitare di lavorare con settanta tabelle semplicemente perché è un'enorme quantità di lavoro: settanta modelli e controller e le loro oltre 4 visualizzazioni, aiutanti, layout e test, per non parlare del problema del carico di memoria dovuto al mantenimento il disegno ind.A meno che, ovviamente, non fossi pagato a ore e abbastanza bene da compensare la ripetizione.

Answer 5

Prima di lanciarti nella realizzazione di 70 modelli, considera questa domanda per aiutarti a decidere:

Ciascuna delle tue tabelle sarebbe considerata un "oggetto", ad esempio una tabella "automobili", o alcune tabelle contengono solo informazioni sulle relazioni, ad esempio tutte le colonne di chiavi esterne?

In Rails solo le tabelle "oggetto" diventano modelli!(Con qualche eccezione per tipi specifici di associazioni) Quindi è molto probabile che se disponi solo di 5 gruppi di funzionalità, potresti non avere 70 modelli.Inoltre, se i gruppi di funzionalità che hai citato sono molto diversi, potrebbero anche essere più adatti nella propria app.

Answer 6

Potrebbe esserci un numero limitato di casi in cui è possibile utilizzare il modello di ereditarietà a tabella singola standard di Rails.Forse tutte le classi di un particolare raggruppamento funzionale hanno gli stessi campi (o quasi tutti uguali).In tal caso, approfitta delle offerte DRYness STI.Quando non ha senso, però, usa class-per-table.

Nella versione classe per tabella, non è possibile inserire facilmente funzionalità comuni in una classe base.Invece, inseriscilo in un modulo.Una gerarchia come la seguente potrebbe rivelarsi utile:

app/models/admin/base.rb - module Admin::Base, included by all other Admin::xxx
app/models/admin/user.rb - class Admin::User, includes Admin::Base
app/models/admin/group.rb - class Admin::Group, includes Admin::Base

Answer 7

È già stato menzionato, è difficile dare consigli decenti senza conoscere lo schema del database, ecc., Tuttavia, mi orienterei verso la creazione di oltre 70 modelli (uno per ciascuna delle tue tabelle).

Potresti riuscire a farla franca abbandonando qualche modello, ma per il costo (trascurabile) potresti anche averli lì.

Non è necessario creare un controller + visualizzazioni per ciascun modello (come ha risposto srboisvert).Hai solo bisogno di un controller per ogni risorsa (che mi aspetterei essere molto meno di 70 - probabilmente solo 10 o 15 circa a giudicare dalla tua descrizione).