ASP.NET MVC Areas: Are they important to a large application?

Question

I am in the process of developing a large ASP.NET MVC application. I am currently working through the mechanisms I'll use to structure my controllers/views. I have see some mention of monorail and it's use of "areas". I have reviewed Haacked's article and it looks like an intresting option. What I would like to know is whether or not anyone has implemented areas in a produciton ASP.NET MVC application and if they have are there any online resources that might help implement the areas and justify their existence.

Answer 1

Me and my team are currently developing a very large application using the ASP.NET MVC framework as the underlying technology. We are using Areas, Strongly Typed View Names and our own version of Localisation. So far it is working together very well.

The deal breaker with ASP.NET MVC for me was going to be that the controller names had to be unique. It was perfectly foreseeable to require a controller for managing stock within inventory and dispatching areas of my application and sorting these was going to be too hard. With areas this is no longer a problem. I would highly recommend using them as Phil Haack has outlined.

Alternatively you could look at Steven Sanderson's implementation where he has taken it a little further, though for us it was not something we needed.

I wouldn't be surprised to see Areas implemented into ASP.NET MVC very soon.

Good luck with your application, I don't think you'll regret choosing ASP.NET MVC.

Answer 2

The support of areas in a large application is absolutely vital in my opinion. It seems quite bizarre to me that Microsoft intends on releasing ASP.NET MVC 1.0 without built in support for areas.

Fortunately, what the MVC lacks in capability it makes up for in extensibility. For example, in S#arp Architecture, as Asaf briefly mentioned, I took guidance from Phil Haack (http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx) and Steve Sanderson (http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/) but modified the merged result to support areas directly under the view folder. (I didn't like that there was a separate "Areas" folder to hold your view areas.) In other words, if you create an "Animals" area with a corresponding controller Animals.AardvarksController, your Views folder would reflect Views/Animals/Aardvarks.

If you're not interested in using all of S#arp Architecture, I would encourage you to at least check out how areas were implemented in this framework for use in your own application. The relevant code includes:

• The reusable area support classes: http://sharp-architecture.googlecode.com/svn/trunk/src/SharpArch/SharpArch.Web/Areas/
• The replacement of the view engine: http://sharp-architecture.googlecode.com/svn/trunk/src/NorthwindSample/app/Northwind.Web/Global.asax.cs
• The declaration of the "area" (this example has an namespace/area called "Organization"): http://sharp-architecture.googlecode.com/svn/trunk/src/NorthwindSample/app/Northwind.Web.Controllers/RouteRegistrar.cs
• The views under the area: http://sharp-architecture.googlecode.com/svn/trunk/src/NorthwindSample/app/Northwind.Web/Views/Organization/Employees/

Incidentally, S#arp Architecture includes a CRUD scaffolding generator which takes into account nested namespaces automatically. As Asaf mentioned, you can find out more about it at http://code.google.com/p/sharp-architecture/

Billy McCafferty