Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

A Task Management System using Three Layer Architecture

0.00/5 (No votes)
9 Apr 2010 1  
This describes a three Layer Architecture with examples

Introduction

Day by day, the real world applications become more and more robust and complex to handle making it very difficult for developers to extend the applications. To solve this problem, developers use a technique. In this technique, they split the total application into parts according to their criteria. In terms of application design, they name the parts Layer and this technique is called Layer Architecture. In this article, I just focus on the three layer architecture.

Description of Three Layer Architecture

In this design technique, the total application is divided into three parts, so, it is named Three Layer Architecture. They are:

  1. Presentation Layer (User Interface)
  2. Business Logic Layer (BLL)
  3. Data Layer

Presentation Layer

The presentation layer is the front-end of the Application Design Architecture which provides the user interface to either programmer of end user. Programmer uses this layer for designing purpose and to get or set the data back and forth.

Business Logic Layer

The business logic layer is the middle layer of the Application Design Architecture which makes the bridge between the front-end and backend. All the business logic is implemented in this layer. This layer is a class which we use to write the function which works as a mediator to transfer the data from Application or presentation layer data layer. In the three tier architecture, we never let the data access layer to interact with the presentation layer.

Data Layer

This is backend of the Application Design Architecture which is concerned about the access, retrieval, update and storage of data. Data layer has two sub-layers. Data Access Layer and the Database. The data access layer is also a class which we use to get or set the data to the database back and forth. This layer only interacts with the database. We write the database queries or use stored procedures to access the data from the database or to perform any operation to the database. In this article, I divide the data access layer into parts, one is DAO (Data access object) containing the real entity and Gateway to access the data from the database.

A Real Time Scenario

In the recent past, I've implemented a project based on the three layer architecture. I'll explain all the terms from the point of this project. The name of the project is “Task Management System” which was built on a partial scenario of a software development team. In this project scenario, all the members of the development team are divided into four categories according to their role. They are- Super Admin, Admin, User and Employee.

The super admin is the most powerful role of this application, he can create and as well as remove admin, user and employee. Admin has the authority to create project, include user in the project, create task and assign the task to users who are included in the project. He can also close the project and task and forward any task from user to user. Both the admin and user can see their task list, comment on that task, attach files with the comment and also forward the task to the user of the project.

Analysis

At first, according to the project scenario, I found out the objects of the project - those are users, projects, tasks and comments. To reduce the design complexity, I've two more extended objects, they are Project Details and Task Details. These two extended objects maintain the relation between Task, Project and User. These six objects are used as the Data Access Object for the Data Access Layer. Gateway classes are used here to access data.

task_mgt_physical_separation.JPG

Here I used Business Logic Layer to communicate Data Access Layer, implement all the business logic and also do some validation.

task_mgt_physical_separation_in_code.JPG

As I said before, this project is designed on three layer architecture and I implemented it as a web based application. Here the presentation layer is the web forms which interacts with the end users and displays data.

3LayerArchitecture11.JPG
Figure 1: Diagram of the data flow inside The Three Layers

In the diagram in figure 1, you see a process. The process goes through the following 6 steps:

  1. The Presentation layer asks the BLL for some object, for example a Task list of a user.

    task_mgt_physical_taskof_a_user1.JPG

  2. The BLL can optionally perform some validation (for example, are all the tasks running?) and then forwards the request to the DAL.
    public DataTable SelectTaskInformationOfUser(string userId)
    {
        TaskGateWay taskGateWayObj = new TaskGateWay();
        return taskGateWayObj.SelectTaskOfOwnerUser(userId);
    }
  3. The DAL connects to the database and asks it for a specific record.
    public DataTable SelectTaskOfOwnerUser(string userId)
    {
        DEC = new DataExecuteClass();
        string selectString = "exec TaskOfUser '"+userId+"'";
        DataTable dt = DEC.getDataSet(selectString).Tables[0];
        return dt;
    }
  4. When the record is found, it is returned from the database to the DAL.
  5. The DAL returns a record to the BLL.
  6. Finally, the BLL returns the data to the Presentation layer, where it could be displayed on a web page for example.

Advantages

There are several advantages of designing applications that are split up into different layers. Most importantly, this form of architecture helps to enforce the principles of high cohesion within system components and low coupling between different components. A system built on these principles will be more robust, easier to adjust, easier to maintain and understand and it allows different software components to be developed in parallel. The key point is that a system should be split into different smaller parts that are as cohesive and self-governing as possible. Each part has distinct responsibilities and interacts with other parts of the system to accomplish its tasks and responsibilities. This also ensures that the systems can cooperate across different platforms and communication protocols and makes it easier to reuse existing solutions to problems often encountered. All in all, these advantages are desirable because they work in the direction of low coupling and high cohesion. The hard part is, however, to implement this in practice and to know when and how it should be implemented. What objects should have responsibility for the different tasks and how do they interact. This is where the design patterns play a vital role.

History

  • 9th April, 2010: Initial post

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here