what is the purpose of "Areas" in MVC2
+3
A:
This is the top hit when googling for "Areas MVC2":
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.
Mitch Wheat
2010-04-26 10:03:08
+3
A:
For a concrete example of when to use areas, consider an e-commerce site. You could have your normal controllers for the public-facing portion of the website, as well as an "admin" area to manage products, categories etc. That way you can have two completely different productController classes which have distinct Details() methods. (one for populating a public facing view with product details, and another for admin users, which might have stats on sales, etc).
briercan
2010-04-26 17:03:44
This is exactly how my implementation of Areas works in the E-Commerce CMS I built for my employer. I have a ProductsController in both the default area and my Admin area. An added bonus of this technique is that my front-facing ProductsController contains zero entity manipulation actions and that means I have very firm control over when and where data can be edited (only in the protected Admin area).
Nathan Taylor
2010-04-27 05:12:35
+1
A:
I'm trying them out in a CMS using the areas for break downs of the content by type. So I have areas for Calendar, News/Blog, Navigation and Pages (a catch-all fall through).
In my brief experience so far, the benefit of areas are:
- Makes it obvious when calling something from a separate part of the application (ie in a RenderAction).
- Makes it easier to see the connection between Models, Views and Controllers for that part of the application as they are no longer all mixed together.
- Registration of routes for the area are right there -- no longer all mixed together.
I do think that acknowledging the first point is important. For some, the extra work to do RenderAction and similar calls to other areas may be a deal breaker. I've also noticed the routing with areas may be subtly different: I relied on a registered handler in web.config but the routing no longer worked for it after moving my catch-all route to an area. I had to add an explicit ignore for the image handler.
Cymen
2010-04-26 17:34:52