Organize Projects and Solutions

You are here:CodeIdol.com >Windows > Visual Studio Hack >Master Projects And Solutions >Organize Projects And Solutions
SAVE
Digg
del.icio.us
Technorati
reddit
Hack 3. Organize Projects and Solutions

Most development projects consist of more than one project and are grouped under a single solution file. How this solution file is created is the first thing to consider when organizing your projects and solutions.
Visual Studio creates a solution for you when you create a new project. The problem with this is that the solution will be named after your project and will be in the same directory as your new project. If you later add an additional project to your solution, your file structure will look something like this:
Folder A Solution File Project File A Folder B Project File B
The problem with this structure is that it is not easy to work with since the solution file is nested inside one of the project directories and references a project file that is contained in a different directory. If you were to move Folder A to a different location, the solution would end up with a broken reference to Project File B. A better way to handle solution files is to always start with a blank solution and then add project files to this solution over time. To start with a blank solution, you simply need to click on FileNewBlank Solution. You can create a directory for this blank solution and add projects to this solution. Your file structure will now look more like this:
Solution Directory Solution File Folder A Project File A Folder B Project File B
This file structure is much more manageable. You can check the entire solution into SourceSafe, you can safely move the solution directory, and you can even zip up the entire directory structure.
1.4.1. Working with Multiple Solutions
Whenever possible, you should stick to a single solution for your development project. But when you get above a certain number of projects in a solution, it starts to become unwieldy for you to manage. It is also inconvenient to have multiple executables or web projects in a single solution, as you will constantly be switching the startup project when you want to run or debug one of the other executables. There are a number of different strategies for working with multiple solutions:
Partitioned solutions under a master solution
 
Often, the number of projects in a solution becomes cumbersome and you need a new method of organization. The best way to deal with this is to create multiple subsolutions that contain the projects for a small section of the overall solution and keep a master solution that contains all of the projects. The reason this is possible is that projects can belong to any number of solutions, whereas solutions cannot belong to other solutions.Figure 1-13 shows an example of partitioned solutions with a master solution file.
Figure 1-13. Partitioned solutions with master solution

 
This method of solution division is ideal when working with large projects because individual developers can work with a more manageable subset of projects. A master solution still exists that can be used by the build process and source control. This organization also allows you to continue to use project references, which are preferable to assembly references[Hack #2] .
Partitioned solutions without a master
 
You can also divide development projects into different solutions without using a master solution. The disadvantage of this method is that you won't have one place to build your project from.Figure 1-14 shows an example of partitioned solutions without the use of a master solution file.
Figure 1-14. Partitioned solutions without master solution file

 
This organization makes the most sense when you are developing a client-server solution. Your client-side application can be one solution, and your server-side application can be another solution. Both solutions will share certain projects, but all of the projects will not be part of any single master solution.
1.4.2. Project Division
One of the big decisions when first starting a new development project is how to divide it into Visual Studio projects. This division into projects is different for each development project, but a general rule of thumb is to divide projects based on layers and dependencies.
Layers are the logical boundaries of your application. They may sometimes coincide with physical boundaries, like between two servers, but not always. The common three-layered application consists of a presentation layer that displays information to the user (ASP.NET web forms, Windows Forms, etc.), a business layer that includes the actual business logic for your application, and last, a data access layer that facilitates the interaction between your application and your database. The number and type of layers can vary greatly between applications. In some instances, the three-layer model is overkill; in other instances, it is woefully inadequate.
If you decide to divide your project into a façade layer, business layer, and data access layer, it is a good idea to have a project for each of those layers. This will enforce your decision by allowing layers to interface with only the public properties and methods of the other layers. You also have to consider dependencies. If you are using custom entities as your method of data transport, then you have to consider the fact that every layer will need to reference your custom entities. You therefore need to separate the custom entities into a separate project. Dividing your projects based on layer also provides a certain level of flexibility when you deploy your application.
1.4.3. Enterprise Templates
Enterprise Templates are a method of providing guidance and setting policy for the structure of a solution. Visual Studio includes a number of prefabricated Enterprise Templates for various general architectures. You can also create custom Enterprise Templates.
Enterprise Templates are available only to users of the Enterprise Developer and Enterprise Architect versions of Visual Studio.
To use Enterprise Templates, you first need to access the Create New Project dialog by navigating to FileNewProject. On this dialog is a folder titled Other Projects, which includes a folder titled Enterprise Template Projects. This folder contains a number of different templates for sample solution and project structures. You could select one of the predefined projects listed here, and Visual Studio would create a solution with a number of different projects. If you select "Visual C# simple distributed application," Visual Studio will create the following projects automatically:
BusinessFacade
BusinessRules
DataAccess
SystemFrameworks
WebService
WebUI
WinUI
Chances are that you don't need all of these projects for your solution, or perhaps you need some of these and some other projects that weren't created automatically. The best solution is usually to start with a blank Enterprise Templates Solution and add your own projects.
You might wonder how this is different from just creating a normal solution. Enterprise Templates provide a number of features that are not available in normal Visual Studio solutions. Enterprise Templates allow you to set policies between projects; you can specify whether certain projects are allowed to reference other projects. For instance, you could forbid the BusinessFacade layer from directly referencing the DataAccess layer.
Enterprise Templates not only provide guidance for your solution and project organization and structure, they also enable a very cool feature in Visual Studio .NET 2002 and 2003; they give you the ability to use folders in your solutions. This feature is enabled by default in Visual Studio 2005, but Enterprise Templates are the only way to enable this functionality in Visual Studio .NET 2002 and 2003. It may not seem like much, but when you have a large number of projects in your solution, it is nice to be able to group them into logical folders. This way, if you are working on the data access layer, you can collapse all of your UI or business projects.
By using Enterprise Templates, you can also take advantage of some prefabricated projects called building blocks that are located under the Enterprise Template Project folder in the New Project dialog. An architect could create a number of Enterprise Templates to dictate how solutions should be built and organized inside his organization. Instead of starting from scratch, developers would use the template to dictate their general architecture.