The layered architecture pattern is the most common among developers. It is useful for programs that comprise several groups of subtasks, each of which is at a different level of abstraction. Each of these subtasks is represented by a layer in the software—a unit of modules that produces a cohesive set of services—and each layer provides services to the next higher layer in a unidirectional pattern.
Each layer has a specific role within the application that is connected to the roles of other layers. For instance, a presentation layer, also called the UL layer, would handle all the UI and browser communication logic while a business logic layer would execute certain business requests.
Other types of layers include the application layer and the data access or persistence layer, which then accesses the database layer. This allows the database layer to be separated and enables you to switch from an Oracle server to a SQL server without impacting the other layers—it allows for lower transition costs.
These layers interact in a unidirectional pattern, such that when a user initiates an input, such as clicking a button, the presentation layer sends messages to the lower layer, the application layer, which, in turn, calls the business layer, then the data access layer that accesses the database. So calls in a layered pattern flow downwards, from a higher layer to a lower one.
Image
Layered architecture patterns are found in many e-commerce web applications and desktop applications. It is also useful for applications that need to be built quickly and for enterprise applications that need to adopt traditional IT processes. Furthermore, a layered pattern is ideal for applications that require strict standards of testability.
Pros:
- This pattern allows for an easy way to write a well-organized application.
- Since it is a popular architecture pattern, developers already have an understanding of how it is used.
Cons
- Complexity and the cost of adding more layers is very high.
- Splitting the layers might be hard