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.