What Is Tiered Development?

for RuBoard

A number of different application design paradigms exist. However, one of the most important and influential is the notion of tiered development practices. Tiered development refers to the idea of separating an application into logical and physical layers with each layer serving a single purpose. There's no limit to the number of layers an application could have, so this style of development is often referred to as N- tier development (where N can be any positive integer).

For instance, consider most of the examples you have seen in this book so far. These examples are all good instances of two-tier design. The Web form or Windows form serves as the presentation layer because its primary job is to display content to the user and gather user input. Most of these examples connect directly to a data source. By storing the data, the data source provides the second tier in the application.

Two-tier application design works well for small applications that will require little maintenance throughout the lifetime of the application. When designing Web applications prior to ASP.NET, performance was more of a consideration because all script in ASP is interpreted. These performance considerations are mostly gone with ASP.NET because everything, including the Web form itself, is compiled. However, the fact remains that having SQL statements strewn throughout the presentation tier of your application makes your code hard to read, manage, and upgrade.

Additionally, the two-tier development model leaves the business logic of your application spread out in the presentation layer, almost certainly with the same business logic repeated on multiple pages. (Business logic refers to the business rules modeled by your application. For instance, not allowing a user to purchase over 100 items in a single order would be a good example of a business rule.) If the business logic in your application changes, it would be difficult for anyone but the original programmer to locate and change all of the necessary business logic code instances.

The larger the application, the more these problems are exacerbated.

A solution to this problem is to insert an additional tier between the presentation layer and the database layer. The job of this layer is to encapsulate business logic and perform data access. In Microsoft .NET, this tier is implemented as an assembly. In the next few sections, you'll see how to implement a simple middle tier for some previous examples in this book.

How Many Tiers Are Enough?

This is an easy question to answer, but difficult to gauge sometimes, in practice. Your application should have as many tiers as conditions require.

For instance, consider the scenario of upgrading a two-tier application to a three-tier application by moving business logic and data access from the presentation layer to the new middle layer. An alternate way to do this is to split this new middle layer into two layers. One layer implements only business logic; the other layer only performs the physical database access for the business logic layer.

Many large applications are designed with this methodology. Though it requires some extra work, the effort is rewarded with a replaceable database layer. In other words, if you need to switch your database back end from Oracle to Microsoft SQL Server 2000 (in case your application grows larger and needs to scale out, for instance), you only need to write a new database access layer and use it to replace the old one.

However, this example is unnecessarily complex in order to explain the concepts in this chapter.

Figure 21.1. The .NET tiered development model.

for RuBoard