Hai bisogno di consigli sul design in Ruby On Rails

Question

Hai bisogno di consigli sul design in Ruby On Rails

#1 da (3 voti)
#2 da (0 voti)

2

Per scopi educativi personali sto creando un sito per una conferenza. Uno degli oggetti che esistono in una conferenza è una sessione, che ha diversi stati e in ogni stato ha attributi leggermente diversi:

Una volta inviato, ha un altoparlante ( User nel sistema), titolo e abstract.
In fase di revisione contiene recensioni e commenti (oltre ai dati di base)
Una volta accettato, ha una fascia oraria definita ma nessun revisore.

Ritengo che non sia la cosa migliore aggiungere attributi "status" e iniziare ad aggiungere molte dichiarazioni if ...
Quindi ho pensato che sarebbe stato meglio avere classi diverse per ogni stato, ciascuna con le sue convalide e comportamenti.

Cosa ne pensi di questo design? Hai un'idea migliore?

object-oriented design ruby-on-rails ruby

posta Elad 21.03.2014 - 12:53

fonte

2 risposte

Leggi altre domande sui tag object-oriented design ruby-on-rails ruby

in che modo ORM è un esempio di accoppiamento di messaggi? Servizi di modelli di domini e container ricchi

score 3 · Answer 1

Ho convenuto che le affermazioni gnarly if e le convalide ActiveRecord condizionali non sono la risposta.

Sembra che la tua idea sia di avere diverse classi come Submission, UnreviewedSubmission e AcceptedSubmission. Penso che questo sia un miglioramento, ma potresti avere problemi nel collegare i dati. Se voglio vedere tutte le presentazioni non verificate, come farò? Se rivedo una richiesta e desidero annullarla, come posso revocare la mia approvazione e recuperare l'elenco dei revisori?

Se stai bene con la perdita dei dati storici, l'approccio sopra potrebbe funzionare.

Vorrei anche considerare di archiviare il modello iniziale di Submission e separatamente, un elenco immutabile di modifiche di stato ad esso. Ad esempio, un oggetto Review può essere creato per significare che qualcuno ha revisionato una submission. Per capire lo stato di una submission, troverai l'oggetto Submission originale e poi passerai attraverso tutti gli oggetti Review. Ci sarebbe una penalizzazione delle prestazioni in fase di esecuzione, ma si otterrebbe il tracciamento della cronologia e convalide più chiare sul cambio di stato.

score 0 · Answer 2

Direi che questa è una di quelle situazioni che potrebbero giustificare l'uso di Single Table Inheritance (STI) . Per le implementazioni delle guide, consulta l' API . La cosa bella dell'utilizzo di STI in questo caso è che si memorizzano tutti i dati in una singola tabella, ma sono in grado di fornire diverse 'finestre' su di essa attraverso i vari modelli figlio. In questo modo si mantengono prontamente disponibili i dati degli stati precedenti e si coprono anche i dati condivisi tra gli stati (potrebbe essere necessario sapere chi ha esaminato una richiesta accettata, ma ciò non avrebbe più avuto importanza una volta programmato).

Spero che questo aiuti,

Niels

PS se qualche altro suggerimento sarebbe utile, fammelo sapere! (Anche se questo è probabilmente più argomento su Stack Overflow. Se ripubblichi la tua domanda lì, fammelo sapere e ti risponderò lì)

PPS riguardo all'opzione di aggiungere mazzi di if-statement: che è generalmente considerato un "odore di codice" e quindi meglio evitare. Leggi questa risposta su SO .