Using patterns to build a robust 3-tier architecture

Many .NET applications do not benefit from a robust 3-tier architecture. Instead they have all their code (UI, business logic, and data access) in one place: the code behind.

The initial development cycle may be shorter, but in the long run you'll find that these applications do not evolve well with changing business needs. They are hard to maintain, nearly impossible to change, difficult to integrate (expose as a Web Services for example), and they do not scale very well (for when your website becomes an instant success!).

Here are some details on the 3-tier pattern architecture in Patterns in Action:

3-tier application model:

 In a 3-tier model each tier corresponds directly to one of the three elements needed in an architecture: interaction, manipulation, and storage. The three tiers or layers are:

Presentation layer — handles external interaction with the user

Business layer — manipulates the information required by the user

Database layer — stores the data handled by the system

Now, 3-tier architectures are widely accepted as a high-level best practice approach. However, as a .NET developer additional questions remain. For example, how is each tier built and and how do the tiers communicate with each other?


Below is a cross-section that shows some of the technologies used and the communication between the layers. The right-hand-side shows some of the key design patterns used in the reference application. Clearly, patterns play an integral role throughout the entire 3-tier architecture.
 

3-tier cross-section: 

Here are some details on the tiers and their relationships:

The PL: The concern of the Presentation Layer (PL) is to present information in a consistent and easy-to-understand manner to the end-user. Patterns in Action includes fully functional implementations of three UI platforms: ASP.NET, Windows Forms and WPF (Windows Presentation Foundation).

From PL to WCF: Each of the 3 UI platforms consume the exact same services hosted under WCF. This service-oriented model is an implementation of the Application Facade Design Pattern. Applications designed this way have the ability to expose their Services (Web or otherwise) with no extra work (other than configuring the WCF host). WCF is truly a powerful new platform!

From WCF to BL: The WCF Service Layer receives messages from the PL. It interprets the message, unpacks the Data Transfer Objects, and orchestrates and coordinates the interaction between Business Objects and Data Access Objects. The Services Layer is also the place where authorization, authentication, data validation, and database transactions are implemented.

The BL: In the Business Layer (BL) you'll find Business objects, such as, Product, Customer, and Order. Business Objects encapsulate business logic in the form of business rules. Business Objects themselves have no knowledge about databases or data persistence, which is handled by the DL.

From BL to DL: In fact, Business Objects do not directly interact with the Data Layer (DL).You don't ask a Product business object to save itself and there are no Save or Load methods on the Business Objects themselves. Instead, persistence is handled by dedicated Data Access Objects (another Enterprise Pattern) that extract data from the Business Objects and subsequently store it in the database.

The DL: The Data Layer (DL) handles the persistence of Business Objects. Patterns in Action offers two different technologies: ADO.NET and LINQ-to-SQL. In web.config you indicate which one to use. ADO.NET implements a 'data provider factory' which uses an abstract factory pattern and returns database specific singleton factories. This example shows that design patterns frequently work together with other patterns. When using LINQ-to-SQL you will see that LINQ generated Entities are mapped to Business Objects.

Following this review, we'd like you to walk away with the following important observation:

Have you noticed that there are no direct interactions between the PL and the BL or DL? In other words, the UI only interacts with the application via the Service Layer. This is by design. The reason is that security, data validation, and transactions are managed at the Service Layer. The UI is never allowed to bypass these important functions. Therefore, all communication with the application must go through this single point-of-entry (Application Facade) which is hosted under WCF.
 

Building a 3-tier application structure

Once you've decided to build your .NET application following a modern, pattern-based, 3-tier architecture, you may be asking yourself: How do I organize and structure my Visual Studio .NET Solution and Projects? Patterns in Action will demonstrate exactly how this is done - again, with great documentation and 100% pure source code.

Below are 3 annotated screenshots that show the Solution Explorer of this reference application.

The first screenshot shows the layers in the application. They have been numbered so that they display in a logical top-to-bottom order.
 

Physical Layers in 'Patterns in Action': 

 The next screenshot shows all 21 projects. Notice the 4 different UI platforms in the Presentation Layer (ASP.NET MVC, ASP.NET Web Forms, WinForms, and WPF). Again, each of these UI platforms consume the exact same services in WCF, which, in turn, rely on the same Service-, Business-, and Data-Layers (discussed below).

Projects in 'Patterns in Action':      

Finally, the third screenshot shows the complete set of re-usable classes, types, and design patterns that you will receive with your Patterns in Action solution:

Classes and other Types in 'Patterns in Action':   



reference: dofactory