N tier Architecture

N-Tier Data Applications Overview

 

N-tier data applications are data applications that are separated into multiple tiers. Also called "distributed applications" and "multitier applications," n-tier applications separate processing into discrete tiers that are distributed between the client and the server. When you develop applications that access data, you should have a clear separation between the various tiers that make up the application.
A typical n-tier application includes a presentation tier, a middle tier, and a data tier. The easiest way to separate the various tiers in an n-tier application is to create discrete projects for each tier that you want to include in your application. For example, the presentation tier might be a Windows Forms application, whereas the data access logic might be a class library located in the middle tier. Additionally, the presentation layer might communicate with the data access logic in the middle tier through a service such as a service. Separating application components into separate tiers increases the maintainability and scalability of the application. It does this by enabling easier adoption of new technologies that can be applied to a single tier without the requirement to redesign the whole solution. In addition, n-tier applications typically store sensitive information in the middle-tier, which maintains isolation from the presentation tier.
Visual Studio contains several features to help developers create n-tier applications:

• The Creating and Editing Typed Datasets provides a DataSet Project property that enables you to separate the dataset (data entity layer) and TableAdapters (data access layer) into discrete projects.
• The LINQ to SQL Tools in Visual Studio provides settings to generate the DataContext and data classes into separate namespaces. This enables logical separation of the data access and data entity tiers.
• LINQ to SQL provides the Attach method that enables you to bring together the DataContext from different tiers in an application. For more information, see N-Tier and Remote Applications with LINQ to SQL.

Presentation Tier

The presentation tier is the tier in which users interact with an application. It often contains additional application logic also. Typical presentation tier components include the following:

• Data binding components, such as the BindingSource and BindingNavigator.
• Object representations of data, such as LINQ to SQL entity classes for use in the presentation tier.

The presentation tier typically accesses the middle tier by using a service reference (for example, a Windows Communication Foundation Services and WCF Data Services in Visual Studio application). The presentation tier does not directly access the data tier. The presentation tier communicates with the data tier by way of the data access component in the middle tier.

Middle Tier

The middle tier is the layer that the presentation tier and the data tier use to communicate with each other. Typical middle tier components include the following:

• Business logic, such as business rules and data validation.
• Data access components and logic, such as the following:
  
  • TableAdapters and DataAdapters and DataReaders.
  • Object representations of data, such as LINQ to SQL entity classes.
  • Common application services, such as authentication, authorization, and personalization.

The following illustration shows features and technologies that are available in Visual Studio and where they might fit in to the middle tier of an n-tier application.

Middle tier

The middle tier typically connects to the data tier by using a data connection. This data connection is typically stored in the data access component.

Data Tier

The data tier is basically the server that stores an application's data (for example, a server running SQL Server).
The following illustration shows features and technologies that are available in Visual Studio and where they might fit in to the data tier of an n-tier application.

Data tier

The data tier cannot be accessed directly from the client in the presentation tier. Instead, the data access component in the middle tier is used for communication between the presentation and data tiers.

The Business Rules Layer

The Business Rules Layer in an N-Tier architecture is that layer that contains the Business logic and / or Business rules of the application. Reserving a separate layer strictly for Business logic in an N-Tier architecture is a major advantage, in that any changes that need to be made to Business rules can be made here without having any effect on other applications.
Assuming that the interface among the different layers stays the same, changes that are made to the functionality / processing logic in the Business Rules Layer can be readily made without having any affect on the others. In the past, many client server applications failed to implement because the changing of the Business rules or logic was such a difficult process.
The Business Rules Layer in an N-Tier system is where all the application’s brainpower resides. It contains data manipulation, Business rules, and all the other important components that your Business needs to survive. If you happen to be creating a search engine and have the need to weight or rate every matching item according to some sort of custom criteria – let us say the number of times a keyword was found in the result of a quality rating – then the Business rules layer should be placed on this layer. The Business Logic Layer does not know anything about HTML – it does not out put HTML, either.
Nor does the Business Logic Layer care about things like SQL or ADO. The Business Logic Layer should not contain any code that enables it to access the database. Such tasks should be assigned to corresponding layers above and below it.

What is business logic?

Business logic is an often overused term that can be used to describe many things and the definitions are typically very verbose. However, a general definition is that business logic is logic that is related to and can be described in terms of the domain in which the application is operating. Of course, this is a rather idealistic definition, but essentially what this says is that business logic is related to the information being manipulated within the application rather than, for example, the logic associated with any of the external interfaces such as the user, the database, etc. As an example, consider an e-commerce site such as Amazon. The domain in which the site operates is the online sale of products such as books, CDs, DVDs, and so on, while the business domain includes concepts such as products, customers, addresses, etc. Here, business logic might involve the process of a customer buying a product, applying discount rules and so on.

How and where is business logic implemented?

Before the introduction of J2EE and, specifically, Enterprise JavaBeans, business logic was implemented in several ways. The first of these was that business logic was embedded within the user interface code, alongside any logic required to present information to the user. While this worked and still works, it does lead to systems that are fragile when it comes to modifying the way that the system works. Also, changes to the user interface code can easily affect the way that the system behaves. At the other end of the architecture, business logic is often tied to the database being used, perhaps being implemented within stored procedures or triggers. Wherever it is located, mixing business logic with application specific code is not good for aspects such as reusability and maintainability. A natural progression from here is to encapsulate business logic inside reusable classes or components. With Java, a possibility is to build JavaBeans - reusable software components that can run within any Java virtual machine. The benefit that this provides over embedding business logic alongside the application specific code is that the application is much easier to maintain. Any changes to the business processes realized by the system are easy to find and easy to change. In addition to this, business logic is now reusable both within the application and within other applications that operate within the same business domain. In other words, more than a single development team within the same company or business area can take the same code to reuse in their application.