MVC3 When To Use Areas?
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?
Answer
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.