Putting controllers into different assembly on MVC project

Billy McCafferty, mentor and leader of the S#arp project, has an interesting post where he justifies the separation of the controllers into a different assembly. It’s not that I don’t agree with his reasons and his objectives (I really do!); I just think that this separation isn’t really needed for guarantying that  you get better code for the controllers.

My rule of the thumb regarding physical separation is a simple: I will only separate code into different assemblies if I need to change the implementation of a contract at runtime or if I want to reuse that code on different projects. Will this happen with the controllers of an ASP.NET MVC project? I don’t know. I guess that it depends on the  project and on the controller. If you’re going to reuse the controller code across different MVC projects, then I guess that you should do that and put that code into a different assembly.  On the other hand, if you’re building a specific controller then I think there’s no need in putting it on a different assembly.

Probably you’ll start like me: code  and refactoring along time, which means that you’ll probably start with a single project and then you’ll refactor it into different assemblies. But don’t forget one important thing: keeping it on the same assembly as your MVC project isn’t an excuse for being sloppy and start hard coding your dependencies into  your controllers.