Project structure recommendation for an opensource asp.net mvc project.

Question

What do you think of the project structure for an opensource CMS application built on asp.net mvc application? The project nickname is "Gol".

The basic requirements are outlined in the following posts.

Ideas for OpenSource CMS in ASP.NET MVC

Currently I am thinking of laying it down like this...

• Gol.Core.Session (contains session manager both real and fake)
• Gol.Core.Caching (contains caching including velocity, enterprise lib. provider)
• Gol.Core.Logging (contains logging components and providers)
• Gol.Core.Instrumentation (contains instrumentation related items)
• Gol.Core.UI (UI helpers, and other things related to UI)
• Gol.Core.Security (security,authentication related things)
• Gol.Core.Utilities (common utility functions like encryption, helper methods, etc).
• Gol.Core.Metadata (metadata manager).

• Gol.Web.Controllers (all controllers goes here).

• Gol.Cms.Contracts (contains the service contracts)

• Gol.Cms.Model (contains the service model)

• Gol.Cms.Services (contains the service implementation).

• Gol.Web (the web project that contains the views)

• Gol.Test (or Gol.Specification)

What do you think? Is the structure overloaded/bloated?

Your thoughts/suggestions welcome based on your experience (nothing specifically do with asp.net mvc).

This may help others as well who may be interested in designing the initial project structure.

Answer 1

I usually structure my MVC projects with the following projects:

 web
    web.Controller
    model
    Business Logic
    Data Access
    Services
    Any Libraries for sessions, caching etc.

You have quite a well structured project although there are a few things I think you can do to improve it.

Create a test project for each layer that you have so that you can isolate the tests. If you change your presentation layer you can dump any tests associated with them and move your bussiness logic easily. I would also create another project for integration tests for each layer I have. This is so that you can exclude them for quicker continuous integration compiles.

I would also not have the UI code in Goi.Core.UI. Your UI code is probably for presentation malipulation and should live in Goi.web

Good luck with your project

Answer 2

For bigger applications I'd highly recommend using MVC V2's areas. Modularizing your work lends itself to long term maintainability. You can find out about them here: http://msdn.microsoft.com/en-us/library/ee307987%28VS.100%29.aspx

From there I'd create a Gol.Areas with all of you area projects in there (they will contain your controllers and views for each area).

I'd also go with a Gol.Communication layer if your dealing with any web servicing.

I'm giving you this advice at an "enterprise development" level.

As for the tests, you might be creating lots of work in trying to seperate your Tests away from the logical tiers. Just a thought.

Answer 3

Start with 1 project and build something functional. Only add new projects as growth demands. I've started new projects like this, planning a grandiose VS solution with an impressive-looking number of separate projects, but it ends up being a waste of time. You'll end up trying to fit your design into your project structure, which is stupid - the project structure is there to help you. The only way to know for sure how you'll need to organize your code is by having code to organize. It's much easier to do it incrementally as you build, than try to do it all upfront.