Coding Professionally Using Layer-Based Architecture
Based on the nature of work a professionally developed application is supposed to do, the organization of code is very important. Today I have decided to write about it as it is one of the things that I came to know about on my first job while still studying in the final year of university.
Prior to that, in our university projects we made applications that had all the code amalgamated into single files or units that made the code look very messy & impossible to work with. As time passes and the code base of an application expands in size, the code becomes unmanageable. You might be able to understand it at the time of writing it, but it will surely make the life of other developers very miserable when they try to figure out what a particular method that is hidden under the bewildering web of other complicated methods actually does. To avoid such a scenario, the industry follows a practice of making applications that consist of ‘layers’. This technique is highly recommended and is followed by almost all of the developers who have an idea about the catastrophe of spaghetti code.
There can be 'n' number of layers in an application, however most applications are divided into three layers; each layer is considered to perform a specific operation and therefore the code that does a certain kind of work is placed in its designated layer. This greatly simplifies code and enhances productivity of developers as they know for example, that if they need to find a certain method related to database operation, they will find it in the Data Access layer and they don't have to scroll through countless other UI code files that have nothing to do with the database.
So, moving on, I was telling you about the three common layers used in most applications. A typical application is generally divided into three components. The first one is the Data Access Layer (DAL). This layer comprises of all the operations only limited to database, its connectivity, methods that expose the database operations, etc. All the codes that have anything to do with the database will go in this layer. All your CRUD operations and other useful methods that query the database should reside here.
The next layer is the Business Access Layer (BAL) or Business Logic Layer (BLL). This layer, as the name suggests, comprises of all the codes that have anything to do with the application's business logic. For instance, if you have to calculate the monthly expenses of an employee and then perform some mathematical operations on the amount calculated, then you would write down such figures in this layer.
The third layer consists of the application itself i.e. the User Interface or front end. For web applications this layer would consist of the application project which has all the application pages or screens. Every page will then call the Data Access Layer via the Business Layer so as to query the database, after which the Data Layer will return the data to the Business layer, and the Business Layer will in turn perform some useful operation on the data, and finally relay it to the UI layer. The end result would be that the UI layer will display the data to the front-end in a user-friendly manner, for example, in a grid. Generally speaking, the Business Layer, Data Access Layer and any layer other than the UI layer/project are considered to be individual class libraries. These class libraries, as we call them in the ‘Dot Net’ world, are merely a collection of classes and files; they are not executable files, they are consumed by the front-end/UI layer/project.
Other layers may be the “Common layer” which holds the codes that are required by every other layer, like a class/file of constants that may be required by the UI layer as well as the Business Layer. In some scenarios the Data Access Layer is divided into further layers, namely, Persistence Layer, Entity Layer, Data Layer etc. All of this is up to the application architect and may differ due to personal preferences and in some scenarios, even the utility. Same is the case with the UI Layer; it may be further divided into two other layers, an Application Layer and the Presentation Layer. It all depends on the need of the hour. There is no rule book or user manual that dictates which one to use. It is completely up to the application architect. As long as this setup helps the code to communicate what it is all about, in a simple manner.
If you want to be a pro when it comes to designing applications, I would highly recommend using Layer-Based Architecture. By using this approach, your applications would be in line with industry standards and it would be easier for other developers to understand the code and methods used.
Disclaimer: The views expressed here are solely those of the author in his private capacity and do not in any way represent the views of Systems Limited, or any other entity related to Systems Limited.