When Rails presenters are a smell and what to do about it
-
Upload
andrzej-krzywda -
Category
Technology
-
view
590 -
download
2
Transcript of When Rails presenters are a smell and what to do about it
When Rails presenters are a smell and what to
do about itAndrzej Krzywda @andrzejkrzywda
helpers presenters
???
Presenters
Remarks
• takes multiple AR objects
• uses the exposed AR state
• returns a hash
• some repetition solved by meta
Remarks
• includes url_helpers
What’s good?
• no need for helpers
• view logic in one place
• better OOP than helpers
• handles non-CRUD views quite well
What’s bad?• ActiveRecord all the way down
• access attributes
• even when we pass domain POROs
• tell, don’t ask
• coupling to AR or POROs
• potentially slow
Are there any alternatives to presenters?
Read models
CQRS DDD
Example
We need events(or maybe not)
rails_event_store
The fastest way to get events in your ugly Rails apps
https://github.com/arkency/rails_event_store
What to do with the past events?
1. RankingHadState 2. turn existing data into events
What if I don’t want events?
Enjoy the coupling and call the read model
directly
Read models• Event handlers
• Customized for the view
• denormalized / derived data
• easy to rebuild
• cache-like
• tell, don’t ask
When to choose read models over presenters?
Choose presenters
• When your app is still very CRUDish
• what you create is what you list
• No goal to escape AR
• No performance problems
Choose read models
• Performance
• When you prefer domain objects not to leak attributes
• show data from different modules
• gateway drug to DDD/CQRS
Read it online
http://blog.arkency.com/2015/05/introducing-read-models-in-your-legacy-application/
Thanks!