Object oriented languages do a good job of helping you learn to separate out the process of working with different data elements. This concept can be extended to get you toward an important software development concept: multi-tier applications.
In the “old days” a program would pull data from a data source, store that information, perform some analysis and process on that data, and then give you a result. Everything was done within one application.
If the data source changes, or if the type of data that was being read changes, the whole application had to change. This can become quite cumbersome, and is prone to lots of potential errors.
A further problem with it, is that the application doesn’t scale well for users. As the data is loaded each time, for each user, lots of users need direct access to that data source. If a server becomes overloaded, there isn’t an easy way to improve performance other than increasing the server’s specs, and that isn’t always an option.
If you add a second server, then it needs the complete application, and data, to operate. If the data is updated on one server, how is it supposed to update on the second server? Data getting out of sync with one another becomes a very real problem, very fast.
A solution to that was to break up programs into logical, and sometimes physical, sections. The basic idea allows for a program to split job functions across different programs, so they can easily be split across multiple servers if necessary.
Where the old form could be thought of as a single tier application, where everything from data storage and retrieval, processing, and displaying the data is done on one machine, we want to look at breaking that up into multiple processes.
Usually a three tier application is designed, as it is the most logical. In that system you would have the following tiers, or roles:
Data Access – This part of the application will be responsible for accessing the data. This will often use a static method from a class that is called to read a data source, and return an object with the requested data.
Imagine, if you would, you have an Employee Database stored in files. In a single tier application, you would probably have a constructor, where you pass the employee number, and it goes into the file to find and pull the information.
If you use a data access object, it would have a static method that takes the employee number as a parameter, and returns an Employee object with the requested employee. The basic code might look something like:
Employee e = EmployeeDAO.getEmployee(employeeNum);You might wonder where this helps. Well, that is actually very simple. Files work for simple information, but as your data grows, both in size and complexity, you probably want to store it in a database.
Instead of writing a new Employee class, or at least updating the class, you just have to update the data access object. Now, instead of pulling data from a file, it pulls it from a MySQL database, or Oracle database, or any other form. The code for the Employee remains the same. In its untouched format, the chances of error go down.
Business Logic – The second tier of your application is the business logic. This is where your data objects will come into play. Not only will they hold information, they will control the logic which is used to update the data.
For example, they might prevent an employee number from being changed, because that is considered immutable data. Or it might specify that in order to have a promotion, you can’t have had a promotion in the last six months.
These data objects will contain, and protect data from being used incorrectly. They will also allow access to the data, but only in a format to return data.
Business logic method will not display data at all. Therefore you won’t see any print commands, or similar types of code where data is written to a screen, file, or back to the data source. That will be done by the third (display) tier which we’ll look at in a minute.
To save data, the object might have a save method, but it will call the data access object to actually save the data. This way it doesn’t have to worry about how or where the data is stored. Consider the following code:
public void save() {
// save the current employee data by passing the object to be saved
EmployeeDAO.saveRecord(this);
}Display Tier – The final tier is to display the data. This may be in the main application, and it calls data to load, and then display. Here you will write data to a screen, by calling the print function, and then passing the results of one or more get methods.
If your application is updated from a batch application to an interactive, the business logic and data access tiers do not have to be updated, only the display tier.
The display tier will handle the formatting of data and how it is to be displayed, if it needs to be displayed, as well as take inputs from the end user. It doesn’t matter if this is via a web app, a console app, or a graphical interface app – the display tier will be built to handle the appropriate method.
Now these tiers may be logical, where you have multiple objects and classes performing those functions, or it could be physical, where you have different applications that speak to one another through a network, or some sort of messaging queue.
A logical separation can easily become a physical separation if it is well planned, thus allowing the simplicity of a single application until it outgrows its resources and needs to become multiple physical applications on different physical servers/computers.
Three Tier vs n-Tier
In a web based application, the display tier is actually broken up into two tiers itself. The first part of the display tier writes to an output stream which is sent to the web browser. This output is rarely stored on the server, and more commonly sent straight to the end user’s browser.
The second part of that tier therefore becomes the client’s web browser. It would utilize the HTML code, as well as CSS and JavaScript to properly display the data to the end user. It would also take user inputs and pass it back to the business logic application, which would in return send data back to the output stream and then the client browser. On and on this process would potentially run.
Additionally, depending upon how the application is written, the business logic tier could be broken down into various servers and services to handle increased workload as the business application became larger and more widely used. Whether that would be in separating synchronous and asynchronous tasks or splitting different tasks would have to be determined by the application architects.
However, a simple three tier application can quickly grow into multiple additional tiers. The term n-tier is often used because we don’t know how many tiers will be used, and we don’t want to limit it to a number, or assume how those additional tiers will divide up the application tasks.
Multi-Tier Applications was originally found on Access 2 Learn
