Organizing ASP.NET MVC Solutions

Question

I have been working on a large ASP.NET MVC 3 application for a few months now. It wasn't until late in the project that I realized that my controllers were HUGE! Part of the problem with these controllers being huge was that I couldn't unit test them.

I've since split the responsibilities of the controllers into four tasks (in my mind):

• navigation
• converting IDs to data objects
• building view models for display
• general-purpose business logic

Since some business logic is shared across client- and server-side code, it doesn't make sense to mix it in with view model builder logic. So, I immediately see the need for at least two projects: view model builders and general-purpose business logic.

I realized that navigation should be the responsibility of the controller, so that logic stays in the MVC project.

I am a little torn about which project should be responsible for converting IDs to data objects. Originally, I had made this the responsibility of the business class/view model builder class. However, I think I would like these classes to work primary with fully-constructed objects. So, I am not sure where in the code this conversion should take place. It doesn't seem to matter where I do the conversion, the code becomes duplicated. I have been thinking about creating adapters in the respective projects that do these conversions and then call the actual business class/view model builder class.

• Has anyone worked in an ASP.NET MVC project that has grown beyond a single project?
• How is logic broken out to keep the size of controllers down and keep code testable?

Answer 1

• Has anyone worked in an ASP.NET MVC project that has grown beyond a single project?

Yes.

• How is logic broken out to keep the size of controllers down and keep code testable?

By putting controllers on a diet.