The Three Layered Architecture

Layers

An application consists of layers, which are abstract horizontal parts. These layers represent the different levels and types of abstraction of the software. The layers help to slice the application into more manageable units and support multiple implementations. Usually, when the user is making a web request, the data flow will pass all of those layers. I believe that each layer should have a separated set of models that shouldn’t be reached from another layer. In addition, Each layer should only be able to reach the layer beneath her or at the same level. I recommend using a data mapper and different projects to keep the separation between the layers and the models. P.S This article explains the three-layered architecture only from a back-end perspective.

Presentation Layer

The presentation layer is the highest layer of the software. It is where the user interface of the software is placed. It contains logic only related to how the data is presented and the beginning of each CRUD (Create, Read, Update or Delete) operation flow. In C# is where all of the controllers and views will be placed. In this layer, the logic should be the simplest.

Business Logic Layer (BL)

As the name of this layer, most of the logic of the application will be placed in this layer. The BL layer should not have intimate knowledge of any data model so it can’t possibly fire a query against the database. The layer input is a data structure received from the presentation layer and the layer output is a data structure received from the DAL. The BL layer allows developers to design applications that support multiple user interfaces, this minimizes the chances of needless code duplication. Usually, this layer is divided into smaller pieces that are easy to manage.

Data Access Layer (DAL)

This layer is separated into two: DAL abstractions and DAL. The data access layer is the layer that implements the communication with the data source (usually a database). A data access abstractions layer follows the idea of “separation of concerns” whereby all of the logic required for your business logic to interact with your data layer is isolated to a single set of classes (layer). This allows you to more easily change the backend physical data-storage technology (move from XML files to a database, or from SQL Server to Oracle or MySQL, for example) without having a large impact (and if done right having zero impact) on your business logic.