Is there a recommended, suggested, or conventional structure for .NET and/or ASP.NET projects?

Question

I'm thinking about starting work on a fairly large scale .NET or ASP.NET project (I haven't decided yet, but it is likely that, eventually, it will be accessible from both a desktop application written in .NET as well as an ASP.NET web application). However, I'm not sure if there's a conventional way to structure the project.

The project itself is a resource/knowledge management tool that tracks a number of knowledge sources - people, publications (books, journals, magazines), web resources, digital documents (including PDF, Word documents, ODF documents, MP3s and more) and others as I see fit. Of course, because its so large, I want to be able to implement and test one section at a time, but have them integrated into a single system.

Once I have a section or two done and tested, I want to release this as an open-source tool. However, if others are going to be working on this, I want to present them with an easy to understand structure. However, I have never worked on an ASP.NET project and I haven't touched .NET since when the 2.0 framework was new. I'm looking for any conventions that exist within the .NET community as well as any general conventions as to how such a large scale project can be structured to make design, development, testing, use, and maintenance as easy and painless as possible for anyone who uses or works on this project.

EDIT 1: I'm not only looking for patterns (like what Toran Billups pointed out), but also directory structures, project structures (as in the VisualStudio project), and documentation structures.

Answer 1

If you are working with the web forms technology and want the ability to create a desktop application with the same code base I would suggest using the Model View Presenter pattern to break out the UI from the business coding. In addition to this approach, I would recommend creating a service layer that handles the logic beyond the Presenter class (including Data Access / Business Logic).

I found that creating a class library to hold this UI agnostic code makes it very easy to reuse this code. This architecture also lends itself to a simple web service transition if you take that route because your service inputs/outputs should be the same in your class library as they would be in a web service (WCF or ASMX)

I would suggest this excellent article from MSDN by the great JP Boodhoo. I follow this same structure and the big benefit is that my UI does not drive my line of business apps. They are also much more maintainable and reusable. I can have a web forms app use the same class library that my WPF app uses.

Answer 2

For code tree layout, I usually do something like this:

projectname/
           /source/
           /source/projectname.sln
           /source/DataAccess/
           /source/DataAccess/DataAccess.csproj
           /database/schema/
           /database/schema/something.sql
           /database/testdata/
           /database/refdata/
           /tools/
           /COTS/
           /COTS/vendorname/
           /COTS/vendorname/somelib.dll
           /doc/
           /build/
           /installer/
           /projectname.build

So the top level directory holds the project's build file. This can be ant, make, etc. We use FinalBuilder. Then you have subdirs for each of source, database, tools, COTS, doc, etc. You may think of others, but these are the obvious ones.

I usually include a build folder for staging the output of a build. This would be where your installer looks for its files.

At the top of the source tree is my visual studio solution file. Each sub-project gets its own subdir which holds its vs project file and everything else. I like to have things encapsulated in fairly small projects, so I might have 10 project in a solution, each with its own subdir under source.

Database scripts can be separated however you like, but try to keep structure and data separate.

Tools is for misc things you need to build this project.

COTS is for external things that you either bought or downloaded that you depend on but cannot build yourself.