Sento spesso a volte parlare male di ActiveRecord da Railsari di tutto
rispetto. L’ultima in un episodio recente di Ruby Rogues.
Mi chiedo se avete registrato la stessa tendenza e cosa ne pensate.
Personalmente finora non mi mai capitato di volermene sbarazzare.
Anzi a volte mi trovo a stupirmi di quanto funzioni bene e quanto sia
potente.
-f
Non so a cosa ti riferisci quindi non posso esprimere un parere nel
merito
di ci che hai sentito. Ma anche se non ho una grande esperienze di
Rails,
ci che trovo fastidioso lo stretto legame tra viste e modello e quindi
l’assenza di uno strato di astrazione fra i due ove necessario, gi
implementato in Rails. e.g. viste che coinvolgono pi modelli non
relazionati. A mio parere ti costringe ad implementare tu stesso questo
strato (con form objects) od a gestire pi tipi di modelli nel controller
(sbagliatissimo, ritengo :).
Altro difetto secondo me dover mettere validazioni che non riguardano
l’integrit dei dati nel modello stesso. e.g. validare che un utente che
viene aggiunto ad un progetto abbia un certo ruolo, nel modello del
progetto.
Non escludo che la mia opinione sia guidata da un approccio sbagliato o
progettazione sbagliata.
Luca
Il giorno 13 ottobre 2014 13:14, Fabrizio R. [email protected]
ha
scritto:
Concordo con Luca che si sente la mancanza di uno strato di astrazione
tra
vista e modello, ma non perch non ci sia, ma perch quello che c’ (gli
Helpers) un modo “alla PHP” di implementarlo, quando invece sarebbe
meglio implementarlo a oggetti, sia per com’ fatto Ruby, sia per
coerenza
col resto. Infatti io quando posso sostituisco gli helpers coi
presenters:
Un altro problema di ActiveRecord secondo me legato agli errori e alla
gestione dei messaggi di errore, che difficile personalizzare a causa
del
legame campo-messaggio d’errore, a mio avviso nella maggior parte dei
casi
forzoso; inoltre il messaggio d’errore dovrebbe essere parte non del
modello stesso ma del presenter del modello, presenter che in
ActiveRecord
manca, come ho scritto sopra.
–
Maurizio De Santis
Il giorno 13 ottobre 2014 13:37, Luca P. [email protected]
ha
scritto:
L’episodio recente a cui mi riferisco questa puntata di RubyRogues:
176 RR Rails as an SOA Client with Pete H.
http://rubyrogues.com/176-rr-rails-as-an-soa-client-with-pete-hodgson/
tra l’altro consigliato a tutti per gli argomenti trattati.C’ una
piccola
parentesi in cui si parla di AR in termini di " e alla fine tirando un
sospiro di sollievo abbiamo rimosso tutti i require ad ActiveRecord"
(una
cos del genere).
Il problema che dici sicuramente presente, molto sentito e di vecchia
data, ma secondo me largamente risolvibile evitando di mettere business
logic negli oggetti ActiveRecord.
Ormai in tutti i progetti sui cui lavoro d’obbligo almeno una cartella
‘app/domain’ e ‘app/services’. Almeno, perch poi ovviamente puoi usare
tutte le convensioni che meglio credi a seconda del progetto.
Effettivamente manca in Rails, nelle guides specialmente, una
indicazione a
non usare AR per la busienss logic. Il fatto che la questione non sia
neanche menzionata strano e pericoloso, specie per chi comincia con
Rails
che rischia velocemente di trovarsi con una codebase ingestibile.
Personalmente uso gli oggetti AR per quello che sono, ovvero un modo
brillante per parlare con il database, validations e callback inclusi.
Tutto il resto lo piazzo altrove.
Riguardo la sorpresa che citavo nel messaggio precendete, magari un p
naive per trovo le opzioni sulle validations molto potenti. Poco codice
per fare davvero tanto.
%i(tos_one_accepted tos_two_accepted).each do |field|
validates_inclusion_of field, in: [true],
on: :create,
if: ->(user) { user.lang == ‘it’ },
message: ‘TOS must be accepted’
end
-f
2014-10-13 13:37 GMT+02:00 Luca P. [email protected]:
2014-10-13 13:53 GMT+02:00 Maurizio De Santis
[email protected]:
Concordo con Luca che si sente la mancanza di uno strato di astrazione tra
vista e modello, ma non perch non ci sia, ma perch quello che c’ (gli
Helpers) un modo “alla PHP” di implementarlo, quando invece sarebbe
meglio implementarlo a oggetti, sia per com’ fatto Ruby, sia per coerenza
col resto. Infatti io quando posso sostituisco gli helpers coi presenters:
Category: Rails Presenters - The Ruby ToolboxCerto, per semmai un problema di Rails, non di ActiveRecord.
Un altro problema di ActiveRecord secondo me legato agli errori e alla
gestione dei messaggi di errore, che difficile personalizzare a causa del
legame campo-messaggio d’errore, a mio avviso nella maggior parte dei casi
forzoso;
Per fare questo puoi usare degli attributi virtuali. Ad esempio
prendiamo
una checkbox.
Di default la mapperesti nel database con un campo boolean. Nel mio
caso,
proprio oggi, la volevo invece
mappare ad un campo datetime.
Ho creato un attributo virtuale con tanto di validazione e messaggio di
errore, poi on before save ho settato
il datetime a seconda del bisogno. Nel form ho poi assegnato la checkbox
all’attributo virtuale. Ho risolto cos molto velocemente.
inoltre il messaggio d’errore dovrebbe essere parte non del
modello stesso ma del presenter del modello, presenter che in ActiveRecord
manca, come ho scritto sopra.
Nella pratica non mi mai capitato di desiderare di mettere i messaggi
di
errore della validazione in un posto diverso che non nella definizione
della validazione stessa. Ovviamente con delle chiavi di traduzione.
–
È da un po’ di tempo che mi limito ad usare Active Record nel senso più
aderente al relativo design pattern.
Parto dichiarando l’oggetto Active Record e le relative relazioni
(has_many, belongs_to, etc).
Se poi l’oggetto resta molto semplice, aggiungo delle validazioni e
qualche
piccolo helper di istanza (pochissimi) o di classe (principalmente
scope).
Allo stesso modo nei Controller mi limito ad usare il classico paradigma
CRUD basato direttamente sull’oggetto Active Record, mentre nelle viste
azzardo degli striminziti snippet di codice, come anche uso gli helper
come
un primo, rudimentale, layer di riutilizzo del codice per le viste.
Questo per mantenere un contatto con la praticità, molte volte mi basta
per
ciò che devo ottenere e il codice resta manutenibile.
E sottolineo come questa fase comporti anche della “sana” duplicazione
del
codice.
Ma quando la complessità aumenta, solo in seguito alla sensazione
ripetuta
di dolore nell’utilizzo, rifattorizzo: rimuovo la duplicazione presente
e
ridistribuisco le responsabilità introducendo principalmente Form Object
(che uso nei controller e nelle viste), Service Object, Validator Object
(sui Form Object, non sui model Active Record), Decorator/Presenter
Object
(per la viste e non solo) e quando serve, anche Cell (nel caso in cui
sia
evidente sia che un insieme di helper, viste e decorator compongono un
widget, sia che tale widget verrebbe usato in differenti contesti).
Questo mi permette di lasciare che gli oggetti Active Record restino
snelli
e con la sola responsabilità del designer pattern che millantano di
implementare ;-), apprezzando tantissimo la loro presenza (come quella
di
Arel e ActiveModel).
2014-10-13 14:31 GMT+02:00 Fabrizio R. [email protected]:
Aggiungo, non vedo molte alternative a reform e per questo ho pensato
che
questo approccio non fosse molto in voga fra gli sviluppatori rails.
Però
da quello che leggo qui forse non è vero. Che dite?
Per ora il semplice uso di ActiveModel mi basta e avanza 
class SignupObject
attr_accessor :name, :email, :age, :accepts_terms_of_service # this
doesn’t necessarily map 1:1 with database fields
include ActiveModel::Model # goodies
end
2014-10-13 17:53 GMT+02:00 Luca P. [email protected]:
Concordo con Luca che si sente la mancanza di uno strato di astrazione
tra
vista e modello, ma non perch non ci sia, ma perch quello che c’ (gli
Helpers) un modo “alla PHP” di implementarlo, quando invece sarebbe
meglio implementarlo a oggetti, sia per com’ fatto Ruby, sia per
coerenza
col resto. Infatti io quando posso sostituisco gli helpers coi
presenters:
Category: Rails Presenters - The Ruby ToolboxCerto, per semmai un problema di Rails, non di ActiveRecord.
S, ci ho pensato quando ho inviato la risposta
Un altro problema di ActiveRecord secondo me legato agli errori e alla
gestione dei messaggi di errore, che difficile personalizzare a causa
del
legame campo-messaggio d’errore, a mio avviso nella maggior parte dei
casi
errore, poi on before save ho settato
il datetime a seconda del bisogno. Nel form ho poi assegnato la checkbox
all’attributo virtuale. Ho risolto cos molto velocemente.
Non so se ci siamo capiti; volevo dire che il paradigma di gestione di
messaggi di ActiveRecord (validates_*_of :field, message: …,
record.errors.full_messages), che il modo di Rails per tirare fuori i
messaggi di errore di un modello, sbagliato in partenza perch si occupa
di elaborare i messaggi (traduzioni incluse) che una responsabilit che
non compete ad ActiveRecord. Questo fa s che io se implemento due
form_for
diversi su di un’istanza di User per esempio ho gli stessi messaggi
d’errore, a meno di evitare l’utilizzo di record.errors ed astrarre
attraverso form objects, come si diceva sopra.
–
Maurizio De Santis
Il giorno 13 ottobre 2014 14:31, Fabrizio R. [email protected]
ha
scritto:
La risposta di Maurizio merita come minimo 92 minuti di applausi, +1 su
tutta la linea
Ju
Societ Cooperativa weLaika
Corso Vigevano 14/B, 10154 Torino (TO), Italy
http://welaika.com - [email protected]
2014-10-14 9:29 GMT+01:00 Maurizio De Santis
[email protected]:
Mi aggiungo all’applauso a piene mani! Evviva le responsabilita’ ben
assegnate!
Cheers,
BrunoQuesta credo sia una delle discussioni più interessante passata di qua
nell`ultimo anno.
Piccola deviazione dall’ argomento: per implementare i form object con
validazione utilizzate qualche gemma, come reform, o li implementate
sempre
a manina?
On 13 Oct 2014 16:52, “maurizio de magnis” [email protected]
attraverso form objects, come si diceva sopra.
Capisco, per scondo me non cos grave. Non so se sia corretto dire che
si occupa di elaborare le traduzioni, visto che di quello si occupa
I18n.
Direi pi che altro che espone i messaggi di errore, ed ha nozione di
I18n
stesso, che forse gi basta per dire che fa troppo.
Ad ogni modo nel caso in cui ci siano due form diversi ed il messaggio
di
errore debba essere diverso per l’uno e per l’altro si pu interrogare
l’oggetto per chiedere che errori ha registrato e gestirli ad un livello
pi alto.
Quindi finora quello dei messaggi di errore mi apre di capire sia il
problema pi sentito. Vi viene in mente altro?
La roba degli errori in s non gravissimo di per s, quanto per il fatto
che cos da anni e non sembra vogliano porre rimedio.
Tempo fa ActiveRecord era abbastanza indietro rispetto a Sequel, che per
esempio supporta le foreign keys nella definizione dello schema da
sempre e
ActiveRecord solo dalla 4.2 (che ancora deve uscire), oppure la DSL per
la
costruzione delle query in ActiveRecord c’ “solo” da quando c’ Arel,
oppure la gestione delle connessioni in multithread rompe… comunque
con
calma mi sembra che l’abbia raggiunto.
–
Maurizio De Santis
Il giorno 14 ottobre 2014 11:07, Fabrizio R. [email protected]
ha
scritto:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs