MVC3 When To Use Areas?

Question

I am working on an agile MVC3 project and it is starting to get rather large, specifically my management section, where the user is able to set a lot of configurations, etc. This is my first MVC3 project, so I am just curious when it makes sense to use areas?

Like how large should a controller for a specific section like management be before you decide to break it up into an area and create controllers for the individual management operations?

Also, when using areas, should I refactor to use areas for everything, or just for the sections that need an area?

Snick

Answer 1

There are as many opinions about how to organize this as there are developers, but my views are as follows;

Controllers should only be responsible for interacting with views. That is, instantiating and populating model objects, retrieving data from your business objects or data access layer, responding to any requests from the page (form submissions, AJAX requests, interface to dynamic resource creation methods/classes (such as creating CAPTCHAs or other dynamic images)), etc. If you stick to that philosophy, their size and complexity should never exceed that of your views.

Areas I tend to use areas to break up the application into sub-applications. For instance, a site may have a discussion forum, product catalog, company information, support database, etc, all of which would be separate areas:

/areas/forum/...
/areas/product/...
/areas/company/...
/areas/support/...

Then, in each area, you might have

/areas/support/{views|controllers}
/areas/support/search/
/areas/support/contact/
/areas/support/knowledgebase/

etc.

Just as in a webforms site where each folder represented a distinct "area" of the website, areas provide another level of organization that lets you keep related controllers, views, etc in a common location, and should be used in a similar fashion.

Prefrontal

Thank you for the detailed answer. This is helpful and I think I am going to implement areas in the next iteration. – Snick

Answer 2

We use areas to distinguish notable separate concerns within the application. Especially separate concerns that may require unique authentication or layout/styling for each area. For example, I'm working on an application that has "modules" of sorts. Each module is an mvc area and each module as a setup section that is also an mvc area. The application has three modules, so that is a total of six areas -- with six user rights to go along with them. This allows each module to have a new "master page/layout" (appearance) and a specific security level.

It helps in separating the code as well; code in AreaA has nothing to do with code in AreaB, but sometimes AreaA and AreaB use common code found in the root of the project.

The non-area parts of the site have things like the user-login, error pages (404, etc), the main "launcher" area to enter the modules, exception handing, and other encompassing things that cross-cut across any of the mvc areas.

Eelworm

Answer 3

Its most practical when you need separate control and reusing controller names. Like you could use it for an administration site, a blog portion, etc.

Grieve