Visual Studio Hacks [Electronic resources] نسخه متنی

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

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:

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

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 File New
Project. 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.