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.
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.