The most commonly used application development architecture, and the one supported by most application servers, is a component-based, three-tier model. Components increase code reuse and simplify development, and three-tier development increases scalability and reliability by isolating the three main logical functions of an application (user interaction, business logic, data storage) from one another.

Neither component-based programming nor the three-tier model is entirely new. Instead, both reflect the current thinking of how to achieve two longstanding goals: write less code, and make the code that is written easier to deploy, scale, maintain, and enhance.

Why Components?

A developer maxim states: "the best line of code is the one you never had to write." This accurately reflects the reality that every new line of code written (or existing line of code that is modified) by a developer is a potential bug. Reusing code reduces the amount of new code that must be written, thereby allowing developers to build applications with fewer bugs and in less time.

By using components, a developer is able to package the binary (compiled) code in such a way that another developer is easily able to discover what functions the component provides (typically by using a programming language tool such as Visual Basic [VB]) and invoke those functions, while the internal workings of the component remain hidden.

Although component-based programming enables reusable code, it is up to the programmer to ensure that the code inside the component is truly reusable. For example, a tax calculation component would not be truly reusable if it failed to take into account the varying tax rates across state and local governments.

Why Three Tiers?

Almost all programs must provide functionality that displays the user interface (UI), performs the main logic of the program, and stores and retrieves data. Though a developer could write a single module that intertwined all three tasks, such an undisciplined approach would quickly become a maintenance and deployment headache. Therefore, developers seek to segment the application’s functionality in layers, or tiers.

As business applications initially moved from mainframe or minicomputer systems to the PC, developers adopted a two-tier strategy, also known as client-server. In the client-server model, the data storage (typically provided by a server running a database management system such as SQL Server or DB2) is separated from the rest of the application (typically running on desktop PCs). Many developer tools sprang up around the client-server model, most notably VB, which dramatically simplified the process of building custom applications that accessed data.

But the client-server model had limitations. The following problems were the most serious:

Difficult to evolve. Because the client piece of a client-server system included both the UI and the business logic, developers updating the UI could inadvertently change the business logic as well.

Difficult to deploy. A client application had to be deployed on the desktop PC of each user who wanted to access the application, potentially requiring thousands of deployments.

Difficult to scale. Each running client connected directly to the database, thereby consuming server resources and often limiting the number of simultaneous users that could access an application.

The three-tier model introduces an intermediate business-logic tier between the UI and the data storage, providing the following advantages:

Increased scalability. Business logic components can be pooled and shared across multiple running clients.

Easier to maintain. Since the UI code is separate from the business logic, the UI can be changed and enhanced without accidentally altering core business rules. In addition, when the business logic must be changed, only a relatively small number of middle-tier servers need to be updated instead of a larger number of desktop PCs.

Shared business logic. Because the business logic is in its own tier (instead of integrated with the UI) it can be shared among applications with different UIs. A tax calculation component, for example, could be used by both a sales entry application and a purchasing system.

Support for multiple interfaces. The same business logic can be used from a Web-based interface and a thick-client interface.