New Post has been published on http://www.ismailkeles.info/the-magic-of-the-three-tier-architecture.html
The Magic of the Three-Tier Architecture
Generally, the architecture refers to the way we split the code that implements a feature of the application into separate components based on what they do and grouping each kind of component into a single logical tier.
In particular, the three-tier architecture refers to an architecture that is based on these tiers: • The presentation tier • The business tier • The data tier
The presentation tier contains the user interface elements of the site and includes all the logic that manages the interaction between the visitor and the client’s business. This tier makes the whole site feel alive, and the way you design it has a crucial importance for the site’s success. Because your application is a web site, its presentation tier is composed of dynamic web pages.
The business tier(also called the middle tier) receives requests from the presentation tier and returns a result to the presentation tier depending on the business logic it contains. Almost any event that happens in the presentation tier usually results in the business tier being called (utilized), except events that can be handled locally by the presentation tier, such as simple input data validation, and so on. For example, if the visitor is doing a product search, the presentation tier calls the business tier and says, “Please send me back the products that match this search criterion.” Most of the time, the business tier needs to call the data tier for information to be able to respond to the presentation tier’s request.
The data tier(sometimes referred to as the database tier) is responsible for managing the application’s data and sending it to the business tier when requested. For the shopping e-commerce site, you’ll need to store data about products (including their categories and their departments), users, shopping carts, and so on. Almost every client request finally results in the data tier being interrogated for information (except when previously retrieved data has been cached at the business tier or presentation tier levels), so it’s important to have a fast database system. In Chapters 4 and 5, you’ll learn how to design the database for optimum performance.
These tiers are purely logical—there is no constraint on the physical location of each tier. In theory, you are free to place all of the application, and implicitly all of its tiers, on a single server machine, or you can place each tier on a separate machine if the application permits this. Chapter 22 explains how to integrate functionality from other web sites using XML Web Services. XML Web Services permit easy integration of functionality across multiple servers without the hassle of customized code.
An important constraint in the three-tier architecture model is that information must flow in sequential order among tiers. The presentation tier is only allowed to access the business tier, and it can never directly access the data tier. The business tier is the brain in the middle that communicates with the other tiers and processes and coordinates all the information flow. If the presentation tier directly accessed the data tier, the rules of three-tier architecture programming would be broken.
These rules may look like limitations at first, but when utilizing an architecture, you need to be consistent and obey its rules to reap the benefits. Sticking to the three-tier architecture ensures that your site remains easily updated or changed and adds a level of control over who or what can access your data. This may seem to be unnecessary overhead for you right now; however, there is a substantial future benefit of adhering to this system whenever you need to change your site’s functioning or logic.
Figure 2-1 is a simple representation of the way data is passed in an application that implements the three-tier architecture.
Figure 1: Simple representation of the three-tier architecture
A Simple Example Using the Three-Tier Architecture It’s easier to understand how data is passed and transformed between tiers if you take a closer look at a simple example. To make the example even more relevant to our project, let’s analyze a situation that will actually happen in TShirtShop. This scenario is typical for three-tier applications. Like most e-commerce sites, TShirtShop will have a shopping cart, which we will discuss later in the book. For now, it’s enough to know that the visitor will add products to the shopping cart by clicking an Add to Cart button. Figure 2-2 shows how the information flows through the application when that button is clicked.
At step 1, the user clicks the Add to Cart button for a specific product. At step 2, the presentation tier (which contains the button) forwards the request to the business tier, “Hey, I want this product added to my shopping cart!” At step 3, the business tier receives the request, understands that the user wants a specific product added to the shopping cart, and handles the request by telling the data tier to update the visitor’s shopping cart by adding the selected product. The data tier needs to be called, because it stores and manages the entire web site’s data, including users’ shopping cart information. At step 4, the data tier updates the database and eventually returns a success code to the business tier. At step 5, the business tier handles the return code and any errors that might have occurred in the data tier while updating the database and then returns the output to the presentation tier.
Figure 2: Internet visitor interacting with a three-tier application
At step 6, the presentation tier generates an updated view of the shopping cart. At step 7, the results of the execution are wrapped up by generating a Hypertext Markup Language (HTML) web page that is returned to the visitor where the updated shopping cart can be seen in the visitor’s web browser. Note that, in this simple example, the business tier doesn’t do a lot of processing, and its business logic isn’t very complex. However, if new business rules appear for your application, you would change the business tier. If, for example, the business logic specified that a product could be added to the shopping cart only if its quantity in stock was greater than zero, an additional data tier call would have been made to determine the quantity. The data tier would be requested to update the shopping cart only if products are in stock. In any case, the presentation tier is informed about the status and provides human-readable feedback to the visitor.
What’s in a Number? It’s interesting to note how each tier interprets the same piece of information differently. For the data tier, the numbers and information it stores have no significance because this tier is an engine that saves, manages, and retrieves numbers, strings, or other data types—to the data tier this data is just arbitrary information, not product quantities or product names. In the context of the previous example, a product quantity of zero represents a simple, plain number without any meaning to the data tier (it is simply zero, a 32-bit integer). The data only gains significance when the business tier reads it. When the business tier asks the data tier for a product quantity and gets a “0” result, this is interpreted by the business tier as, “Hey, no products in stock!” This data is finally wrapped in a nice, visual form by the presentation tier, such as a label reading, “Sorry, at the moment this product cannot be ordered.” Even if it’s unlikely that you want to forbid a customer from adding a product to the shopping cart if the product is not in stock, the example (described in Figure 2-3) is good enough to present in yet another way how each of the three tiers has a different purpose.
Figure 3: Example of information exchange among application tiers
The Right Logic for the Right Tier
Because each layer contains its own logic, sometimes it can be tricky to decide where exactly to draw the lines between tiers. In the previous scenario, instead of reading the product’s quantity in the business tier and deciding whether the product is available based on that number (resulting ultimately in two database calls), you could have a single stored procedure named add_product_if_availablethat adds the product to the shopping cart only if it’s available in stock. In this scenario, some logic is transferred from the business tier to the data tier.
In many other circumstances, you might have the option to place some logic in one tier or another or maybe in both. In most cases, there is no single best way to implement the three-tier architecture, and you’ll need to make a compromise or a choice based on personal preference or external constraints.
Furthermore, there are occasions in which even though you know the rightway (in respect to the architecture) to implement something, you might choose to break the rules to get a performance gain. As a general rule, if performance can be improved this way, it is OK to break the strict limits between tiers just a little bit(for example, add some of the business rules to the data tier or vice versa), ifthese rules are not likely to change in time. Otherwise, keeping all the business rules in the middle tier is preferable, because it generates a cleaner application that is easier to maintain.
Finally, don’t be tempted to access the data tier directly from the presentation tier. This is a common mistake that is the shortest path to a complicated, hard-to-maintain, and inflexible system. In many data access tutorials or introductory materials, you’ll be shown how to perform basic database operations using a simple user interface application. In these kinds of programs, all the logic is probably written in a short, single file, instead of separate tiers. Although the materials might be very good, keep in mind that most of these texts are meant to teach you how to do different individual tasks (for example, access a database), and not how to correctly create a flexible and scalable application.