What's your typical structure of an ASP.NET solution?

Question

As the title says, I'm interested to know how you typically structure your ASP.NET solutions.

I'm especially interested in ASP.NET WebSite solutions, but information abut other types (WebApplication, MVC) might be interesting as well.

Some specific questions:

• what/how many projects/assemblies does the solution contain
• how do you name your class library projects
• what namespaces do you typically have
• do you have multiple namespaces per project/assembly or do you have a strict 1:1 relation
• etc.

Thanks

Answer 1

I typically use the name of the application for a solution name (using the generic "Solution" project type), then have SolutionName.Site, SolutionName.Domain, SolutionName.Persistence, etc... for the projects it contains. It seems to make it easier to deal with all the references.

I'd like to see other peoples answers though. While this is the best way I've found I can't shake the feeling that there might be a better one.

Answer 2

One of my projects looks like:

• Sln
  • Sln.Core
  • Sln.Core.Test
  • Sln.Data
  • Sln.Data.Test
  • Sln.Web
  • Sln.Web.Test

Core is the domain model and domain services, as far as they can be done without stepping into persistence. Data is the persistence layer, which basically means FluentNHibernate definitions and concrete implementations of interfaces defined in Core. Web is the front-end layer.

Answer 3

I have done something similar to Justice. But with fewer projects (and faster compile time)

Sln

• Project.Core
• Project.Web
• Project.Test

Project.Core will look like this

• Repository
• Domain
• Presenter
• Service
• View
• Common

I don't really get an benefit from multiple (more than 3) projects. You don't gain testablility, and your compile times get much longer.

Also, the first thing I do when I get a Web Site project is convert it so a web application. But overall, my projects don't change when I switch between Web Sites and Web Applications.