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 ASolution File Project File A Folder BProject 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 File
Solution DirectorySolution File Folder AProject File A Folder BProject 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.
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:
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.
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] .
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.
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.
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.
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.
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.
|
To use Enterprise Templates, you first need to access the Create New
Project dialog by navigating to File
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.