2013-05-09 10 views
18

Stiamo costruendo app che hanno modelli che non sono componenti del database. Siamo curiosi di sapere cosa stanno facendo gli altri nella comunità dei binari per affrontare questo argomento.Rails - Dove (directory) per inserire modelli che non sono record attivo

Siamo alle prese con dove metterli.

avremmo dovuto:

app/models/domain 

o

app/domain/models 

o forse

app/models # Business Models 
app/models/ar # Active Record Models 

o forse

app/models/domain/ # Business Models 
app/models/domain/ar # Active Record Models 

Parte di questo è che siamo alle prese con quanto siano vicini agli standard dei binari e quanto creare una struttura che sia adatta a ciò di cui abbiamo bisogno.

Se pensiamo agli oggetti come servizio oggetti, potremmo avere

app/models/service-object 

e

app/models/ # For plain active record 

Un altro itinerario per andare verso il basso non è avere roba all'interno app, ad esempio

/service_objects 

invece di

/app/models/service_objects 

Presumibilmente, se vogliamo l'accesso tramite un'applicazione rails che stiamo meglio di utilizzare app/al fine di usufruire di convenzione sulla configurazione.

+5

La directory è denominata "modelli". Non si chiama solo "discendenti di active_record". Li ho solo messi insieme e ho buttato in cima modelli Mongoid :) –

+0

Puoi metterli in 'lib' se vuoi davvero attaccare con AR-solo nei modelli – Raindal

+1

Mi piacerebbe riconsiderarli in' lib' ma è ancora un'opzione . Mi piace incollare file in lib che considero buoni candidati per l'estrazione in gemme per il riutilizzo. –

risposta

12

Nella mia esperienza, la divisione di dove si mettono questi modelli si riduce a ciò che rappresentano funzionalmente nel contesto specifico dell'applicazione.

Di solito mi occupo di app/models per i modelli basati su risorse. Se quel modello rappresenta una risorsa che viene istanziata e manipolata dalla tua applicazione, va qui. Non ha bisogno di essere AR o db backed.

Se il modello offre una funzionalità coerente ma varia in base ai parametri, fornisco loro una directory di primo livello nell'app. Come ad esempio app/mailersapp/observers ecc. Tuttavia, se si dispone di una risorsa che richiede un osservatore, potrebbe non avere senso avere una dir app/observers con un solo file al suo interno.

Tutto il resto va in lib. Ci sono alcuni motivi per cui questo è preferibile.

  1. È possibile scegliere quando richiedere i file in lib. Puoi essere molto più selettivo su quali file vengono caricati all'avvio dell'app. Se metti tutto in app/models non hai granularità su ciò che viene caricato.

  2. La classificazione dei modelli durante la crescita dell'app è più facile in lib. Certo, puoi creare uno spazio dei nomi in app/models ma diversi livelli di nidificazione in app/models finiscono sempre male. È meglio mantenere il namespace in lib.

  3. Le pulizie sono molto più semplici quando hai le cose nel loro posto funzionalmente corretto. Non è una risorsa? Non è un osservatore? Deve essere in lib. L'intera ragione per cui stai pensando a questo in primo piano è di fornire la scoperta agli sviluppatori in futuro.

14

Per gli oggetti di servizio di solito li si trova direttamente nella directory dell'app app/services/. Anche i lavoratori e i serializzatori seguono questo schema app/workers/app/serializers/. Per quanto riguarda i tuoi modelli che non sono AR, puoi comunque inserirli nella directory dei modelli. Questo è solo il mio punto di vista.

+0

+1 Ciò è utile, grazie. Siamo un po 'preoccupati che con l'aumentare delle applicazioni potremmo ritrovarci con 34 modelli Active Record e 12 Record non attivi e che quindi i modelli avrebbero un miscuglio di 46 insieme. Potrebbe essere ok, ci stiamo solo interrogando su quel potenziale futuro. –

+2

D'accordo con questo: a un certo punto, se hai modelli non-AR stabili che si adattano a funzioni specifiche, puoi sempre estrarli in Moduli. – mikeryz

+0

Beh, si tratta anche di separare le preoccupazioni dalle applicazioni. Non vuoi che una singola applicazione diventi così grande da non poterla gestire. Ad esempio, quando un'app diventa troppo grande, prenderei in considerazione la possibilità di separare l'autenticazione nella propria applicazione e seguire quel modello, quindi semplicemente comunicare attraverso le API. –

1

Se si dispone di classi che non sono modelli, ad esempio rappresentano forse un modulo, direi di andare avanti e inserirli in lib.

Se sono ortogonali all'applicazione, ovvero: è un'interfaccia utilizzata per chiamare un'altra applicazione, è possibile includerla come una gemma privata o pubblica in base alla sua applicabilità al resto della comunità.

Alla fine, non importa. Scegli una cosa e concorda con il resto della tua squadra. Spostare le cose dovrebbe essere abbastanza semplice, specialmente se si aggiunge qualsiasi cosa si decida a utilizzare per il percorso di carico per l'applicazione ($LOAD_PATH += '...').

9

Se sono modelli, è necessario inserirli in app/models poiché questa directory è destinata ai modelli e non solo alle sottoclassi di ActiveRecord.

+0

funziona bene, lo sto facendo con i binari 5 –