Layers of a Windows Application

A Windows application can be divided into a number of logical layers. Your decision on which layers to implement and enforce typically depends on your quality of service (QOS) requirements.
For example, if your application is a stop-gap, possibly throwaway, system with low scalability and maintainability concerns, you might choose to implement only a couple of layers (UI and database). If, on the other hand, you are optimizing your architecture for varied physical deployments, high scalability, multiple user interfaces (Smart Client, Mobile, Reports, and so on), and a high degree of reuse, then you will opt to abstract your application into many more logical layers—you might even decide to create a framework that supports your layers. Most enterprise-level applications written today employ some version of the three primary layers:
user interface, middle tier, and database. Each of these layers might then be divided into additional layers. The following discussion presents each of these layers and some of their common divisions. Any combination of these layers may make up a Windows application.

User Interface A user interface layer provides a window to the application for users. This
layer is typically responsible for getting data from the middle tier and displaying it to the user.
It is also responsible for controlling how a user interacts with that data. This includes data
entry, validation, creating new elements, search, and so on. The UI layer is also in charge of getting the user’s modifications back to the middle tier for processing. The user interface layer is
often a layer by itself. However, it is also sometimes divided into one or more of the following
additional layers:
■ Presentation (or user experience) This layer defines only the presentation portion of the
user interface. This is the portion responsible for laying out the user interface. Think of
this code as the code inside of the FormName.Designer.cs, InitializeComponent method in
C#. Visual Basic hides this code from the developer. In both cases, Visual Studio is trying
to abstract the code for the forms engine and promote the use of the form designer tools.
■ User interface code This layer is where developers place the code to interact with the
user interface. The layer is typically embedded with the form. There is a partial class
associated with each form in both VB and C#. You put your code in this class and it gets
compiled with the form. The code that goes in this layer is to respond to events such as
loading a form or clicking a button. You might decide to abstract the code to respond to
these items into a separate user interface interaction layer. The code that would get compiled
with the form would then simply delegate calls to this layer. This will increase your
reuse if you intend to implement different forms that do the same thing or a new user
interface.
■ Business logic interaction code You might create this layer if you do not wish to tie the
code used to interact with your business layer (middle tier) to the user interface code.
This can be helpful if you intend to plan for the replacement of your user interface. For
example, you might create a Windows-based client today but have a plan to move to
Extensible Application Markup Language (XAML), an Office Client, or something even
further out.

Middle Tier The middle tier is where you house your business logic. This is often referred
to as just the business layer. However, this tier typically includes a lot more than just business
logic. It might include components for handling caching, logging, error management, and so
on. You might use the Microsoft Enterprise Library (or a similar library) in this tier. The middle
tier typically runs on an application server such as Windows Server and Internet Information
Services (IIS). However, you can create your own middle tiers (using things like Windows
services and sockets). The middle tier is sometimes divided into one or more of the following
additional layers:
■ Business layer (or business services) This layer is where you put your domain objects
and their business rules. You might be writing stateless components that work with
Enterprise Services, real object-oriented business objects that run in process, or simple
data transfer objects (DTOs) with processing services that work across remoting channels. In any case, most applications define a business layer. This isolates the business
logic so it can be reused, remain stable (as UIs get rewritten and modified), be
easier to change, and so on. As an example, a business layer object might be an Invoice
class. It might contain properties that define an invoice and methods that save and
load the object. These methods and properties will define the business rules for the
given object. These rules should be validated before the object is sent to another layer
for processing.
■ Application layer (or application services) This layer represents the plumbing to make
your application work. This plumbing typically solves QOS requirements such as “the
application must log errors or cache data for performance.” You want to keep this code
isolated from your business logic. Sometimes this code gets put into a framework. You
can also consider the Microsoft Enterprise Library as part of the application layer. Examples
of an application layer might include a Log class that contains methods to log certain
events, such as errors.
■ Database layer (or database services) This layer abstracts the retrieval and storage of
data in your database. This code is sometimes combined with the business layer. However,
this tight coupling can make the code harder to understand, more brittle to change,
and less reusable. As an example, the database layer might contain static (or shared)
methods that work to save and retrieve data from the database on behalf of the business
layer. An example might include an InvoiceData class with a method like GetInvoice that
returns a DataSet with invoice data. The database abstraction layer is often part of the
database layer. However, it typically does not reside on the database server but on the
middle-tier application server. That is why it is discussed here.

Database Layer The database layer represents how you manage the data in your application.
For most enterprise applications this means a relational database, such as Microsoft SQL
Server. The database layer is responsible for saving, retrieving, and ensuring the integrity of
your data. The database “tier” is sometimes divided into one or more of the following additional
layers:
■ Database layer See the previous “Middle Tier” section.
■ Stored procedures This layer represents the SQL or managed code used to select,
insert, update, and delete data with the database. It also includes any database-defined
functions you might create.
■ Integration services This layer represents how the database works with other data
sources for integration purposes. In SQL Server this is SQL Server Integration Services
(SSIS) or the older Data Transformation Services (DTS).
■ Database tables, log, and indexes This layer represents the actual data in the system,
the log of activity, and the indexes used by the database software.