Controller reponsibilities, anemia and me

Ian Cooper has written an excellent essay on the Fat Controller where he describes the bloating of controllers due to too much responsibility (of various kinds).

Looking back to one of my last projects where we used MVC for the first time, it is startlingly clear with hindsight that we took some wrong steps... our controllers were "fat" with far too much orchestration of and complete knowledge about the domain objects themselves.

More importantly the domain was completely anemic, due mostly to the entities being pre-generated via codesmith from database tables. What we were left with were effectively DTO POCO objects - good for persisting and passing around, but very little else; hitting the buttons on the benefits of the Anemic Domain Model, but bad in rectrospect with my architecural glasses!

This ultimately meant that the controller had everything injected into it via an IOC container - repositories, utilities (small versions of services) and anything else it needed to service the request with complete control.

This is going to be a common mistake, I believe, of those starting out with MVC and in fact a lot of people are vocal about these concerns - take a look at some of the links that Ian points to in his post.

I now know what I did to be wrong and I ask my inner architect to forgive me - I feel it in my bones the more I read back on the basics like Separation of Concerns and Single Responsibility Principle... and more importantly Domain Driven Design.

Without making that mistake and ultimately learning from it though, I don't think I would have truly seen the advantage of a rich domain model and services; reading books and posts about the theory really doesn't match up to personal experience of a D'oh moment.

Time to dig out Eric Evans' DDD book once again and flagellate its principles into me, along with the basics. Oh yes! DRY me, SRP, LOC, LOD and SOC it to me, oh yes!