Question

I am part of a development team implementing a large application. There are several layers to the application, and we’d like to make the organization of files as easy to maintain as possible, but also follow best practice.

Here is an example of how this is laid out based on MVC convention.

UIProject
- Controllers
  - HomeController.cs
  - ErrorController.cs
  - PersonalInfoController.cs
  - BaseController.cs
  ...
- Views
  - Home
    - Index.aspx
    - Home1.aspx
    - Home2.aspx
  - PersonalInfo
    - Step1.aspx
    - Step2.aspx
    - Step3.aspx
    ...
  - Shared
    Site.Master
    Error.aspx
    ...

However, we have realized that the functionality of PersonalInfo has grown, and really should be broken down into multiple controllers. We’d like to organize them in a subfolder of the Controllers folder. Something like this:

Controllers
  - HomeController.cs
  - ErrorController.cs
  - BaseController.cs
  - PersonalInfo
    - Step1Controller.cs
    - Step2Controller.cs
    - Step3Controller.cs

This can be done, each of these controllers would be within a PersonalInfo namespace. A Route can be mapped using the namespace argument.

The real issue comes in with getting MVC to find the associated view. I have found two ways to get around this. One, by clanmonroe.com, handles this by inheriting from a base controller that specifies a hardcoded viewpath. Another, by Stephen Walther, more simply suggests providing the view path in the call to the view.

Both of these methods seem to work, and I’m more partial to the first method. However, they have drawbacks. Mainly, that we now no longer force the convention. That is, Step1Controller.cs could have an Index Action, but the View could be named foo.aspx.

Ideally, we’d like a way to implement an organized approach using MVC natively, w/o quirky workarounds. Is there an established best practice for situations like this, or at least a good recommendation?

Answer 1

This sounds (more or less) like the new areas feature in ASP.NET MVC. According to ScottGu:

Areas provide a means of grouping controllers and views to allow building subsections of a large application in relative isolation to other sections. Each area can be implemented as a separate ASP.NET MVC project which can then be referenced by the main application. This helps manage the complexity when building a large application and facilitates multiple teams working together on a single application together.

It’s not implemented exactly as you describe it, and rather than a sub folder within Controllers, it expects you to split your areas into seperate projects. Each area can then contain both controllers and views.