When we try to find solutions to problems, we often think about things or scenarios similar to the problem at hand. As with everything else, software is no exception. For the majority of developers, the problem will boil down into this:
- Obtain user input
- Perform calculations
- Read or write information to a data source, and
- Ask the user for more input.
Although this scenario has been around for decades, and is one of the most common patterns developers face writing any kind of application, they are unaware of an elegant way of writing the application’s architecture.
The answer of course lies in a multi-tier architecture approach, which lets us write each of the three main functions of a program as independent modules:
- Get user input
- Perform the calculations of the program’s problem domain
- Store or retrieve data in some long-term database
The multi-tier architecture can be further defined as a three-tier architecture, that contains the three modules as the main focus of the application’s architecture.
Lets look at the modules individually.
Presentation Layer
To the user, the presentation layer is the application itself. It is what the user sees and interacts with. To a developer, it is the layer where all of the GUI code will need to be written that allows the user to interact with the other layers.
It is important to realize that the presentation layer is just as important as the other two layers — and often times, even more important. Proper user interface design is essential in allowing the user to navigate and use your program with as few hurdles as possible. Unfortunately, a lot of developers do not follow guidelines, and more often, theme their applications without understanding the purpose behind theming. For Windows-based applications, it is essential to read the Windows User Interface Guidelines.
The presentation layer is most well known for it’s event handlers when dealing with user requests.
Business Logic Layer
This layer’s responsibility deals with solving the problem domain. The problem domain is another way to state the task which the application is meant for, the business logic. Does it calculate insurance rates based on some criteria? Does it schedule client appointments? These kinds of questions fit into the problem domain.
At this layer, most of our case scenarios become apparent through our classes and data structures. Often times, a BankAccount, Customer, Manager, or Service class will be present.
Often times, it useful to document the interaction of the components within the business logic layer, especially if they are complex (but it’s even more useful to make them simple in the first place!). Visual algorithm explanations like flow charts and state charts are very useful in getting a good idea of how this layer works.
The business logic layer is most well known for it’s calculation-intensive functions.
Data Access Layer
Often times the most intuitive and simplest layer is the data access layer. The sole responsibility of this layer is to read and write data from and to a source. The source is almost always a database of some kind. For our purpose, lets use MySQL as a popular database choice. The logic of the data access layer is as follows:
- Receive a request from the business logic layer asking for some data
- Retrieve the data, job done
- Receive a request from the business logic layer asking to insert some data
- Write new data, job done
Although simplified to a point, it is not unreasonable or uncommon of a data layer to function in this exact way.
It is often times helpful to abstract away the data source, so that the rest of the application is unaware (and rightfully so) of where the data is stored. The side benefit of this is that we can re-write the data access layer to use another source, but the interface between the data access layer and business logic layer will remain untouched.
The data access layer is well known for long-term storage, availability across different mediums and environments, and constant read/writes from and to the storage medium.
Putting It All Together: Application Controller
For most of the desktop-based applications, an Application Controller is needed. Because there are very few ways to intuitively write a three-tier application on the desktop, we need a controller that will take input from the presentation layer, call a business logic layer method, which in turn will read/write data, and finally, present the results to the user once this is finished.
The three-tier architecture is best present on the web, where the presentation, business logic, and data access layers can be completely remote and controlled by a framework designed for this kind of usage, such as ASP.NET.
Example Application in C# with WinForms.
To show the three-tier architecture in practice, I have written an example application that displays a collection of customer information in a table, using WinForms as the GUI framework and Access 2007 as a single-file database. It is thoroughly commented and highly recommended that you go through it to understand the application of the three-tier architecture better.
Download Example Application for Visual Studio 2008 (118 kb, Includes Source and Release Build).
Conclusion
The three-tier architecture is not a new concept. It has been used for decades, but many developers are still not taking advantage of this simple, intuitive architecture-level design pattern.
The most important thing to understand is when and when not to apply this type of design. As already mentioned, if your application is doing
- Get user input
- Process data
- Store and/or retrieve data
you would strongly benefit from this design pattern.
Comments