Introduction
In this post I'll present a possible setup for a .NET solution which respects (as much as possible) the following aspects, patterns and software engineering practices
In most of the samples presented in this blog I'll adhere to this kind of solution setup (e.g. here and here)!
The solution should have as few external dependencies as possible. All external libraries (of course we don't count the .NET framework here) on which the solution is dependent should be (if possible) part of the solution tree. Then you can always (if you have your solution tree under source control -- and you definitely should!) check out the complete solution tree on any machine (e.g. on the build server or on a new developer machine) and just build the solution and run the unit tests without any further manual intervention needed.
Each project of the solution has a corresponding test project where you implement all your unit tests (and/or integration tests, acceptance tests, stress tests, etc.) for the respective project. So, if you have a project in the solution called Domain you should automatically have a additional project in the solution which you might call Domain.Tests.
Separation of Concern (SoC) suggests us to split the whole solution into several projects. I often have at least 3 types of projects. In a typical WinForms based application these might be
- Domain - contains the domain model with it's domain entities, services, factories and repository interfaces
- DataLayer - contains the NHibernate XML mapping files and the implementation of the repositories
- Application (or PresentationLayer) - contains the application or presentation logic, the application shell, the views, presenters and/or application controllers
Of course each of those projects has a corresponding Tests project.
Depending on the complexity of the solution there might be even more projects.
Normally I have a Dev folder on one of my (local) hard disks. The Dev folder has at least two sub-folders OSS and Projects. In the OSS folder I have a copy of the source or binaries of all open source software I use in my projects. As you can see below I have downloaded Castle, NAnt, NHibernate, NUnit and the Rhino Tools.
The green check marks on Castle, NHibernate and Rhino Tools show that these folders are under source control (SVN in this case) and that I have the most recent version of the source.
In the sub-folder Projects I put all the solutions we develop for our customers.
Sample Solution Structure
Now let's have a look at the structure of a sample solution. Let's assume that it's a WinForms based application and call the solution DemoSolution.
In the Projects folder I create a sub-folder with the same name as the solution, in this case DemoSolution. In this solution folder I create at least the two sub-folders SharedLibs and src.
The folder SharedLibs contains all the external assemblies my solution depends on (e.g. NHibernate, Castle, 3rd party WinForm Controls, etc.). The content of the SharedLibs folder varies depending on the needs of the solution. In the sample solution I have presented here we have the following files in this folder
Important: Each project of the solution which references one or several of those external libraries points to this SharedLibs folder! That is: never reference an assembly from the GAC (except the .NET libraries of course).
The folder src on the other hand contains our own source code for the solution. The Visual Studio solution file *.sln I put directly in the src folder. Normally the VS solution has the same name as the solution folder (in this case DemoSolution.sln). For each project of the VS solution I have one sub-folder. In this case we have 6 projects in the solution, three of them containing the code which makes up our application and the other 3 projects containing the code of the corresponding (unit-) tests.
Summary
I have presented you a possible structure for a solution you develop. This structure tries to satisfy various requirements implied by commonly used patterns and software engineering practices.
.