4 ms·
Service Objects (No More Fat Models)
- rorykoehler 10y agoThis is how I get all my teams to work. The code goes in app/services folder though. Lib is for 3rd party stuff. A project I worked on last year also implemented what they called 'use-cases' which were essentially model-view classes to extract and prepare data for the views.
- gjorquera 10y agoYeah, app/services might be a better fit. I'm glad that there are teams stearing away from fat models. Or fat anything, actually, as they usually violate the SRP. How did the 'use cases' work for you?
- rorykoehler 10y agoUse cases are essentially classes that hold large sql queries etc to prepare data for use in the view. We were working on analytics visualisations for large volumes of data.
- deleted 10y ago[deleted]
- warseph 10y agoToo bad not that many people seem to do this. Fat models are increasingly difficult to maintain on large scale projects, yet most developers are encouraged to go that way when they start learning rails, and many don't ever realize how problematic this can be in the long run.
- janci 10y agoMartin Fowler calls this Anemic Domain Model antipattern. http://www.martinfowler.com/bliki/AnemicDomainModel.html http://www.martinfowler.com/bliki/AnemicDomainModel.html
- gjorquera 10y agoVery interesting article. I understand how what I'm suggesting can lead to an Anemic Domain Model antipattern, but I doubt that Martin Fowler suggests to have fat domain models with extremely low cohesion. I will, without a doubt, check out the Domain-Driven Design book that Martin Fowler refers to. Thanks for the comment.