This 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.
Use 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.
Too 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.
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.
7 comments
[ 6.5 ms ] story [ 53.7 ms ] threadA 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.
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?
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.