Should MVC Controller be in separate DLL?

Question

I've created a .NET winforms MVC. The Controller and View are in the same EXE. Model is in a set of DLLs that get used by several groups. The MVC is very explicit. Model knows nothing of Controller and Controller knows nothing of View. I'm thinking to put the Controller in its own DLL so that it can be unit tested. Highly unlike someone will reuse the controller. Unit testing is the only reason I have for the move into a DLL.

Conceptually, should the controller always be in the same assembly as the View? What are reasons for/against keeping them together?

Answer 1

Separation of controllers and views are an abstract concept. There's no strict rule that you should physically keep them separate (just like tiers in a three-tier application). However there might be some advantages in either approach.

Separating assemblies has the following benefits:

• Reduces the possibility to accidentally couple views to controllers and breaking the separation.
• Makes it easier to edit views without recompiling controllers at all (which is great from a deployment perspective).
• Building views and controllers become separated, so you can test the one of them even if the other does not build at all.

However, it might be unfeasible for small projects. For very small projects you might want to ship a single executable and nothing else along it. Also, you might not want to create 3 separate projects.

Hey, you might not wanna unit test it at all ;) Ouch, my head is hurt, where did this big brick come from? :))

Answer 2

Thanks. Why do you say, "However, it might not be feasible for small projects."? Given what you've described above and the ability to unit test the controller should both be a project size independent advantage.