Skinny Controller, Fat Model

time to read 3 min | 432 words

imageScott Bellware has a post about Responsible SRP, he presents the Ruby's idiom of skinny controller & fat model vs. the .Net one of a service layer. He links to this post from Jamis Buck, which explains the Ruby concepts much better. This is also something that is annoying me about my current application, Rhino Igloo doesn't really provide the same level of separation that I consider essential, and as a result my controllers are doing way more than I wish them to. I probably should have broken at least some of them up to services.

I find myself troubled, because while I agree with all that Scott says in this post, and most certainly with Jamis about the overall direction, I can also see the scaling issues of this approach.

The problem is that when you have even a moderately large application and you keep pushing things to the model, it will go beyond fat, it will be obese. You can see some of the tricks to manage it here (I was surprised that I was able to follow them, actually, very neat), but this is most assuredly something that the RoR crowd has already reached.

Let us take the example of the User model, and assume that I would structure my application this way, I don't see it working. My IAuthorizationService has roughly 25 methods already (I am thinking of breaking it up, that is too much), and trying to put them, plus the IAuthenticationService and the various things that the User already does into the User model would create something that would be hard to follow. It certainly wouldn't be in keeping of SRP.

Another approach is to use mixins in Ruby to separate the functionality into different files and mixed it into the User model. I don't really like it, but that is perhaps a matter of taste.

Again, another matter of probably biased conceptions, but I truly like it much better when I can wire up another implementation rather than start modifying code when I need to make a change to the code. My ideal would be a lot of very small classes, all collaborating in order to get some result. This, to me, gives a lot of flexibly and power when I come to utilize them.

I would be interested in getting response from the Ruby community, what happens when the model get too big? How do you break it up then?