Question

In the latest release of ASP.NET MVC 2 they have launched the concept of areas as supported by MS. However to perform this areas concept one has to create multiple separate projects. One project per area. In ASP.NET MVC 1 there were many other ways out there to support areas where you would still be working within the same project. This post is not about whether areas are important or not but what a proper implementation would be. What is your preference for working with areas and why? What do you think of this new multi-project way of performing areas?

Here were the pre 2.0 ways to implement areas:

http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx

http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/

http://devlicio.us/blogs/billy_mccafferty/archive/2009/01/22/mvc-quot-areas-quot-as-hierarchical-subfolders-under-views.aspx

I am about to start working on a very large ASP.NET MVC project (and can't wait to dig into the 2.0 preview) and am wondering if I should use this new areas implementation or what we have already proved to work.

OTHER TIPS

Since the release of ASP.NET MVC 2 is sometimes in the future which is uncertain, I'd recommend that you do what has been offered by MVC 1. But it'd be great to implement your projects with the area feature in mind so that you could extend your existing solution much easier later on if needed.

I'd recommend you look at ScottGu's blog posta about MVC 2 novelties. There's also a nice screenshot of file/folder structure with areas.

My advice to you would be this:
If you plan to develop your huge web app in MVC2 I suggest you do take the path of using already implemented areas capability. By the time you finish developing it, MVC will ship and areas will be supported anyway.

Just don't reinvent the wheel and produce some sort of your own solution with this.

But if you won't start in V2, go with Haack's solution of areas.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top