In earlier chapters we learned about 3-tier architecture programming. Now we learn more elegant Universal Layered Architecture (ULA) concept.
In a 3-tier application, business routines are called in response to events in user interface. So, even here the front end and middle tier are somewhat entangled.
The ULA tries to eliminate this problem.
ULA organizes a database application in following layers conceptually.
1. User Layer 2. Business Layer 3. Data Layer
4. User Connection Layer 5. Database Layer
6. Data Connection Layers
Here is a brief discussion of functionality of each layer.
User Layer
The user layer is typically the front end. It may be a browser, VB forms etc.
This is the only layer that interacts with the user. It should contain no business logic altogether – either implicit or explicit. It is aware of only adjacent business layer.
Business Layer
It contains all business logic including calculations and validation. It processes request from user layer and places the results in data layer. It requests data from database through data connection layer.
Data Layer
All data is maintained in this layer and displayed in user layer. It is similar to client side ADO record set but not exactly the same in the sense that it is required even we use any other data connection method other than ADO.
User Connection Layer
It connects user layer and business layer to data layer.
Database Layer
It is the physical database.
Data Connection Layer
This layer communicates i.e. reads/writes from/to the database. It may be composed of DAO, RDO or ADO etc.
There are several points to be considered. First of all, the data layer consists of data sets. It is conceptually different from record sets! We keep current and modified values of each field in data set. When required, we update the database with new values. Of course, you can use ADO record set to use as your data set.
However, if you base your application on data sets rather than ADO record sets, then you have no trouble to adopt any new technology that comes beyond ADO!
All you need to do is just change your data connection layer – without affecting any other layer!
Take another example. Suppose you presently have an application with VB forms as front end. You can convert the user interface browser based by just changing user layer only. All other layers need not to be touched!
Similarly, if you migrate to different database say from Oracle to SQL server and vice versa, only the database layer will have to do the necessary change. All other parts of your application will remain fine!
Now you probably realized that ULA is more refined than typical 3-tier architecture. It offers more flexibility and easier to maintain! Isn’t it? This concept is quickly gaining popularity and in near future we are likely to see all database applications to follow this trend.
The Layered Architecture Development System (LADS) can be diagrammatically shown as in figure 21-1.
Figure 14-1
Remember that it is the code architecture, which determines layering, not the physical location of modules!
This chapter servers only a basic introduction to ULA. For more information and implementation of ULA please see references such as 15, 24 etc.
USER LAYER – VB FORMS, HTML DOCUMENT ETC.
DATA LAYER – ADO RECORDSET ETC.
USER CONNECTION LAYER
DATA CONNECTION LAYER – ADO ETC.
DATABASE LAYER – ACCESS, ORACLE, SQL SERVER, SYBASE ETC.
BUSINESS LAYER (DLLs ETC.)
It seems fine, but can you give an example of how to implement the whole thing?
Frankly speaking, implementing the whole thing is quite demanding! That's the main reason why this architecture is not followed so widely still now.
Before discussing the implementation of ULA, I like to discuss the necessity of ULA first in more detail form.
The easiest client server system consists of database at backend and user interface on front end. Look, there is no separate business layer here. Then where do we keep our business logic in 2-tier system? Well, we mangle some business logic into database itself (in the form of stored procedures) and the rest into user interface itself. In 2-tier applications, we mostly use data bound control. Remember, whenever a control is data bound, our movement is restricted to a great extent. First of all, you can never create 3-tier/layered applications with data bound controls because their very name violates the 'isolation' of layers/tiers concept!
You will definitely ask what is the problem with 2-tier applications. Well, 2-tier applications are very easy to develop (with the consequence that they are very difficult to maintain). Here the programmer does not need to scratch his/her head with many technical implementation problems. In these cases, often the 'connection' part of the system remains hidden from the programmer. For example, consider Oracle - Developer combination that is quite popular. Here you have only one way to implement your business logic – just before modifying records in database. You achieve this task by writing some code in user interface as well as in the database. Now what is the problem with this thing?
Well, there are lots of problems. First of all, ask yourself - what a database is meant for? Obviously for storing data. Isn't it? When you write stored procedures on database, it has to execute them. It creates an extra burden on database. Secondly, with data bound controls, you are always connected with database. More users mean more connection with database. More connection means more process of different requests. So, there is a good chance that the database will soon bog down under such heavy load. Wouldn't it be nice if we connect the database, fetch the query, disconnect it, process the query and then again just connect and save modified data. Well, ULA actually does that (we'll discuss this again later).
Next problem is that 2-tier applications are often monolithic. An application made of Oracle - Developer will need to be discarded entirely if I ever want to
use another database say SQL Server. But in ULA, if you change database only database layer and connection layer need to be updated. And that's really nice.
Unfortunately, problem of 2-tier doesn't end here! Since the user interface here is tied up with business logic, change in one affect another to a great extent!
(This change can occur in ULA also, but there the problem is much less since business logic operates on data set rather than directly on user interface).
So, the main point of saying all this gibberish things is that we want to make an application that is easily MAINTAINABLE i.e. changing/modifying any part of the application should be as easy as possible. It should not any way hamper any part of the system what it should not touch.
Hmm…, I am sure that you're feeling beleaguered by all these hi-fi terms! Rest assured, thing would become clear gradually.
Let me take the simple example of Car database system that we covered in earlier chapter. I'll tell you how to implement it using ULA. Granted, there's very little business logic in this very example, but it servers our purpose anyway.
First we need a database. Let's make our database in Access. Create all the tables and relate them with appropriate keys. So our database layer is done.
Next comes data connection layer. We shall use ADO for this layer. All we need is to create a DSN to tell ADO what database to connect using which driver. And that's completes our botherations with this layer.
The trick comes with data layer. We shall use 'data set' here. Can't we use client side ADO record set here? Yes we could! We can simply consider ADO record set as data layer. But we can do something more! Why not create user-defined arrays and populate them with ADO record set data? I know, you're going to grudge why should am I going to make it so cumbersome. Wait, it has a purpose! Suppose, you use ADO record set as your data layer. After 5 years from now, there may come another more advanced technology say VDO (no pun attached).
If you make a separate data layer (using data sets with arrays) - all you should do is to change the connection from ADO to VDO and populate your existing data sets with VDO record set (or what so ever) instead of your current ADO record set. So data layer is made of data sets, which is very similar to arrays that hold your data. Does it make sense now?
The very next layer is user connection layer. It has the responsibility to display contents of data layer into user interface. It is not very difficult. We have to write a function, which takes a data set as input and displays appropriate values
in relevant fields in user interface. This is somewhat resembles showing elements of an array into some fields.
We encapsulate all our business logic in business layer. Hey, I like to point out that business logic does not always mean commercial logic! It can be engineering or even artistic logic! This layer typically deals only with data layer and data connection layer. It processes data in data sets as per business requirement and then asks data connection layer to implement new data set values in the database. The actual coding of business layer is indeed a very complicated process. However, this is the big picture.
Lastly, the user layer or what the user actually sees or interacts with the system.
It can be VB forms, web browser or your own front-end tool. We only connect user interface with data layer. In ULA, user layer should not contain any business logic including data validation! Suppose, we have a VB form base front end now. If the client wants to access it through web, we just have to replace user layer with HTML forms - so easy!
I think that's enough for your mental tonic. Now venture yourself in this wonderful concept. Good luck!
Schematic diagram of various architectural implementations
2 – tier architecture
Figure 14-2
3 – tier architecture (simplified form of ULA)
(Shown here using ADO but can be implemented without it also)
Figure 14-3 Some
Business Logic
Some Business Logic
Data read from ADO Recordset
ADO Recordset updated with modified data
Universal Layered Architecture
Figure 14-4
Communicates with database
ADO Recordset
populates data layer and vice versa
Data is taken to user layer through User Connection for showing.
After user makes any change to data, it is again carried to data layer, where business layer processes the data. Finally modified data is saved into database.
Processed data again refreshes data layer
Data is read from data layer into business layer and processed
Can you still explain what exactly layers are?
Layers are program modules. It can be CLS/BAS files (if you write them in VB) or C/CPP files (if you code them in C/C++) and so on. In the runtime they will be DLL/EXE or application server files. So, layers are something using which, you organize your code for best maintainability.
Where do I use Object Oriented programming in layered application?
Typically, it is in the business logic layer where you have the freedom to adopt object oriented programming. However, if you like, you can code business layer in procedural programming language as well.
Does my database table design affect if I adopt object-oriented programming?
No. Database table design is generally independent of what methodology (i.e.
object oriented or procedural programming) you adopt in business layer.