The next logical step is to separate the tiers so that the application can be run on three separate computers. This implementation, where the user interface, business rules and data services are designed to run as three separate tiers, is known as a 3-tier application (although all 3 tiers could, if we wished, be run on a single machine).
|
|
Further refinement of the application may lead to more than three tiers being implemented. For example, the administrative functions in the case study that's designed in this book can be implemented as a separate user interface tier, or a Web interface may be provided as an alternate interface to a client based interface.
Applications that are designed to run in two or more separate tiers are known as n-tier applications, where n is the number of separate tiers (although the term is most frequently used to refer to applications that are divided into three or more tiers).
It's important to understand these models if we are to appreciate the design and programming presented in this book, since the application we'll develop is based on the 3-tier model. Let's just recap on the structure of the standard model for a 3-tier application:
-
User tier – This tier presents the user interface (UI) for the application, displays data and collects user input. This tier also sends requests for data to the next tier. This tier is often known as the presentation layer.
-
Business tier – This tier incorporates the business rules for the application. This middle tier receives requests for data from the user tier, evaluates them against the business rules and passes them on to the data tier. It then receives data from the data tier and passes this back to the user tier. This tier is also known as the business logic layer.
-
Data tier – This tier communicates directly with the data store (SQL Server database, other type of database such as Oracle, Exchange data store, Excel workbook, etc.) and passes data between the data store and the business tier. This tier is also known as the data layer.
Benefits of N-Tier Development
One benefit of separating applications into distinct pieces is that it enables parallel development of the different tiers of the application. For example, one developer (or a team of developers) can work on the user tier, while another writes the business tier, while yet another works on the data tier.
This separation also provides encapsulation for the different tiers and components, which can result in a more robust application. Each tier (or layer) is treated as a black box by the other tiers. Only clearly defined inputs and outputs from each tier can be seen by any of the other tiers.
Using these tiers also allows for easier maintenance and support, since it's easier to change and upgrade a single specific component than to make changes in a monolithic application. If the business rules of an n-tier application are changed, it's only necessary to change the software in the business tier on one server. In a monolithic application, a change in the business rules would mean updating the software on every computer that was running the application.
Most importantly, these logical layers offer the greatest flexibility in distribution, as the tiers could reside anywhere from a single desktop to servers and clients around the world (in other words, it's easy to turn the logical tiers into physical tiers). This enables the application to scale easily from the desktop or workgroup application level to the enterprise or Web application level. It also offers the side benefit of being able to place the different tiers on computers that are optimized for roles as servers or as clients, which enhances the performance of the application.
The principal benefit of a well-designed distributed application is an application that can scale well: handle more throughput with the same performance only by adding more hardware (so no code changes are required).
Developing complex applications is not a trivial undertaking, and several studies have shown that, unfortunately, the failure rate for large software projects is unacceptably high. Using a methodical approach to developing applications can reduce the failure rate. This kind of approach is called a software development process.
Comments