Qualcuno qui usa DTO per trasferire i dati dal controller alla vista? Se sì, dove consiglieresti di archiviare quei file?/apps/dtos e quindi consentono loro di rispecchiare la struttura dir delle viste? Qualche raccomandazione sul test di questi animali con rspec?ruby on Rails dto objects - Dove li conservi?
La convenzione Rails non prevede l'uso di livelli distribuiti per i livelli controller e vista. La separazione è lì, ma è logica e relativamente sottile/leggera rispetto ai tipi di framework che vedi in Java land.
L'architettura di base è che il controllore imposta variabili istanza che sono disponibili nella vista corrispondente. Nel caso generale, le variabili di istanza saranno istanze di modelli o raccolte di istanze di modello (provenienti dal database). I modelli dovrebbero essere il nucleo della tua logica aziendale. I controllori coordinano i flussi di dati. Le visualizzazioni lo mostrano. Gli helper vengono utilizzati per formattare i valori di visualizzazione nella vista ... tutto ciò che prende un valore di modello e fa qualcosa solo per scopi di visualizzazione (potreste scoprire che un metodo di supporto usato ripetutamente potrebbe effettivamente essere migliore sul modello stesso).
Tuttavia, se si scopre che una vista richiede la conoscenza di molti modelli diversi, potrebbe essere più semplice avvolgere i modelli in un altro oggetto a un livello superiore di astrazione. Niente ti impedisce di creare oggetti record non attivi che raccolgono e coordinano i tuoi modelli AR reali. È quindi possibile creare un'istanza di questi oggetti nel controller e renderli disponibili per la vista. In genere devi avere un livello di complessità piuttosto intenso nel controller per aver bisogno di questo tipo di cose.
Tenderei a lanciare tali oggetti in app/modelli - Rails carica già tutto in questa directory, mantiene le cose facili da un punto di vista di configurazione/aspettativa.
se vieni da un .NET o J2EE sfondo che si può pensare di modelli come DTO. Potresti o meno essere sorpreso (e possibilmente felice) di sapere che Rails non fa le cose in questo modo per convenzione.
In particolare, non è affatto necessario trasferire formalmente (o memorizzare) oggetti serializzati tra i controller e le viste. Le variabili di istanza (in genere i valori degli attributi del modello) create nel controllore sono disponibili all'interno della vista gratuitamente, come previsto dal framework, senza necessità di ulteriori sforzi di programmazione.
Quello che è stato detto è che in generale, questo è un lavoro che viene gestito da 'aiutanti'. Fondamentalmente aiutano a formattare gli oggetti del modello per il consumo della vista dalla vista. Quindi non è sicuramente una mappatura dei concetti 1-1, ma questo è il pensiero nel mondo delle rotaie
Si prega di non ascoltare le altre risposte. Sono terribili. Gli aiutanti di rotaie sono terribili. Usare i modelli di rotaie ovunque è terribile. Ti supplico, progetta la tua applicazione correttamente e decidi se hai bisogno di DTO o meno. Decidi se vuoi effettivamente avere modelli di rails per gestire cose diverse dalla comunicazione con il database. Decidi se in realtà non vuoi avere un livello tra la tua app e i binari e così via e così via. Il design delle rotaie è adatto solo per piccole app o app che devono essere sviluppate in modo super veloce. Ma se non è qualcosa di banale e ti aspetti di svilupparlo per un po 'di tempo, ti preghiamo di investire il tuo tempo nella progettazione corretta. Non aver paura di rompere le comodità di Rails. E possa la forza con te.
Grazie Toby. Ci vorrà un po 'di tempo per abituarmi, ma vedo il pensiero. Apprezzo la risposta ben articolata. –