views:

496

answers:

3

I'm surprised I can't find more discussions out there about an issue that is really bothering me on our project using ASP.NET MVC.

How can you deal with a Visual Studio solution that has multiple projects? The MVC framework has the Models/Views/Controllers folder in the main project. But what if you want to break up your solution into multiple projects along logical groupings and bring the models/views/controllers along with it? When I think ahead to the end of the project, there will be many classes in each of these folders. It doesn’t paint a cleanly organized structure that will aid maintenance. We’d like a way to either move the classes to the projects that they relate to or at least use a folder structure to aid in the organization.

I assume that one option would be to use the same namespace in all of the other projects as is used by the main project, but I’m not a huge fan of that approach b/c this is not the approach that we’ve normally taken when defining our namespace.

I suppose we could at least create sub folders inside of the M/V/C folders and not carry forward the folder names to the namespaces. I’m assuming then that the classes could be found?

Some background on our project: It is a public facing web site that has many business transactions that the user can perform (about 50-60). Each transaction has a series of web pages that the user navigates through, in order to accomplish the different services provided by the site. We are using a single controller for each transaction (there have been long discussions on whether we should have a controller defined for each transaction or if we should use a higher level grouping and therefore reduce the number of controllers, but some information that we've encountered on the web (http://codebetter.com/blogs/ian_cooper/archive/2008/12/03/the-fat-controller.aspx) brought us to this decision.)

What are some recommendations? Have others solved this issue in a way that they are happy with?

Thanks Jon.

+2  A: 

Have a look at Areas.

Areas is a concept borrowed from MonoRail, which organizes controllers into logical folders.

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

Robert Harvey
+1  A: 

I always delete the "models" folder and reference separate class libraries that represent my business logic layers and data access layers. I also have some solutions where my controllers are kept in separate projects from my views. I agree that in larger applications, the single project model is inappropriate. Even in smaller apps, especially where model code must be shared with other applications, putting model classes in the actual MVC project is a bad idea.

Matt Wrock
A: 

Areas are supported in Asp.Net MVC2.

Scott Gu has a blog talking about the Area Support here.

From his post.

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

J.W.