Multi-Tiered Applications

In complex applications, we generally do not want to think about applications as containing all of the data, data access, user interface, and business logic into a single set of code. Now some applications will have more complicated layers, additional layers, or hybrid layers, but the basic idea is here.

Little changes can be difficult to manage, and flexibility with your application can be a real challenge, especially if you want to develop code for desktop, web, tablet, and other sources.

Therefore, we often look to multi-tiered applications to separate out the system. Most commonly, we will have three tiers, Data Access, Business Logic, and User Interface (UI). Any one of these tiers should be able to change, without changing most (if any) of the other tiers.

Logical or Physical Separation

One common question is do you use a logical or physical separation. I.e. can you have 3 or more separate executables running. The answer is “yes – but it depends”.

So you will always want to logically separate out your layers. However, for small apps it may not make sense to have multiple psychical applications, at least not initially until your applications become more complex.

In other cases, it cannot be helped but to separate physically at least partially. For example, a Web or Mobile App will almost never be part of the data layer.

Separating physically allows for you to increase the number of users, because the parts are not all sitting on the same machine. So if you had an application which allowed 100 people to use it simultaneously on a single tier system, you could run 300 to 1,000 easily on a multi tier system, and upgrade the components as necessary based upon where the system performance was degrading.

Data Access

The Data Access (DA) tier is how we get data from a persistent stored location. This Data Access may access data from a file, a database, a non-relational database, etc. How it gets the data to rest of the application doesn’t matter.

In fact, you should be able to change data sources and move to a different source, without issue, if you simply set up your data access objects correctly. This allows you to move to a system which is faster, or cheaper, or able to handle larger data sets if needed, without any change in code for how the logic or the UI components work.

Often the DA objects will act as a factory to allow you access to a new object, completely hiding how the Data Access works. All it needs to do is return the object of the type you expect.

It’s methods might include updating, adding, deleting, as well as getting a list of items, a single item, or searching for said items.

Business Logic

The Business Logic is where most of the classes methods will come into place. It is called “Business Logic” because often businesses have a lot of written, or some unwritten, rules about how work is to be done.

For example, think of a school management system. You have classes a student can take, and so you might have a student.register(classID) method. If you allowed them to just register for any class we pass them however, there could be some major consequences.

For example, what if the class has a prerequisite that the student hasn’t taken yet? Or what if the class is in a different major? Or the student is already enrolled in too many credit hours?

These are all examples of business logic that the system would need to either accept or reject the request based upon the rules set up by the school.

Other examples, for example in a game, might be you cannot skip to mission 6, without going through and completing missions 1 through 5. Etc. Some rules are “impossible” to break, other’s need to be identified and coded.

The Business Logic classes have to be able to get data from the Data Access classes to verify the rules can be followed, and there is information that is needed. Likewise, they will need to update the Data itself, if the rules allow it, by passing an object to the Data Access class which will then save it.

The Business Logic doesn’t care how the data is saved, where it is saved, etc. It only does the saving, and lets the Data Access Layer deal with it.

Once the Business Logic Layer accepts the data as presented, and it will then pass it on to the User Interface Layer. It may do so by passing on another data stream such as JSON or XML data, or it might just allow access to the end user.

The User Interface Layer

The end layer will be a User Interface (UI) layer. It may not even exist for batch jobs, or it might be highly involved.

This is where the end user will interact with the application. It may be through a console, or a GUI. It might be through a mobile or web app.

You may even have multiple types of UI layers. For example, consider social media apps like Facebook, Twitter, etc. They all run on the computer, through a browser. However, they also have phone apps, and tablet apps – which means they run on iOS as well as Android. This complexity allows for a lot of flexibility.

Advantages of 3+ Tiers

As in the previous example, where you have multiple apps this allows you to easily reuse sections, especially since they are both physically and logically separated.

Another benefit is slitting development work. In this manner different teams can work on different portions, allowing for faster development. Your developing and testing can run concurrently so the timeline is more compressed. And if you move to a different UI, you can reuse many of the same components.

3+, n-Tier, and Hybrid Layers

So this is a common question, what is beyond 3-Tier, and do you ever need it. The answer is: It depends. It depends upon your application, the needs of the users, the number of users, etc. Spreading the logic out allows for faster performance, as long as it has an appropriate back-end network that can handle it.

Consider something like Google where they have machines which crawl the web looking for new content, others which rank the content, others which do translations, etc… all so it can eventually process through it’s index until it finds you what you need.

Hybrid layers can combine multiple aspects, often UI with Business Logic. They may, and should still be logically separated, however, consider a Web Interface which has the UI and maybe some of the business logic as it is processed while the user enters form data (preventing the leaving of some data blank, etc).

Multi-Tiered Applications was originally found on Access 2 Learn