Before you begin: Join our book community on Discord
Give your feedback straight to the author himself and chat to other early readers on our Discord server (find the “architecting-aspnet-core-apps-3e” channel under EARLY ACCESS SUBSCRIPTION).
https://packt.link/EarlyAccess
In this chapter, we explore the inherent concepts behind layering. Layering is a popular way of organizing computer systems by encapsulating major concerns into layers. Those concerns are related to a computer vocation, such as data access, instead of a business concern, such as inventory. Understanding the concepts behind layering is essential, as other concepts were born from layers and are very common.We start this chapter by exploring the initial ideas behind layering. Then, we explore alternatives that can help us solve different problems. We use anemic and rich models and expose their pros and cons. Finally, we quickly explore Clean Architecture, an evolution of layering, and a way to organize layers.This chapter lays out the evolution of layering, starting with basic, restrictive, and even flawed techniques, then we gradually move toward more modern patterns. This journey should help you understand the concepts and practices behind layering, giving you a stronger understanding than just learning one way of doing things. The key is to understand.In this chapter, we cover the following topics:
- Introducing layering
- Responsibilities of the common layers
- Abstract layers
- Sharing a model
- Clean Architecture
- Implementing layering in real life
Let’s get started!
Introducing layering
Now that we’ve explored a few design patterns and played with ASP.NET Core, it is time to jump into layering. In most computer systems, there are layers. Why? Because it is an efficient way to partition and organize units of logic together. We could conceptually represent layers as horizontal software segments, each encapsulating a concern.
Classic layering model
Let’s start by examining a classic three-layer application design:
Figure 14.1: A classic three-layer application design
The presentation layer represents any user interface that a user can interact with to reach the domain. It could be an ASP.NET Core web application. Anything from WPF to WinForms to Android could be a valid non-web presentation layer alternative.The domain layer represents the core logic driven by the business rules; this solves the application’s problem. The domain layer is also called the business logic layer (BLL).The data layer represents the bridge between the data and the application. The layer can store the data in a SQL Server database, a NoSQL database hosted in the cloud, a mix of many data sources, or anything else that fits the business needs. The data layer is also called the data access layer (DAL) and the persistence layer.Let’s jump to an example. Given that a user has been authenticated and authorized, here is what happens when they want to create a book in a bookstore application built using those three layers:
- The user requests the page by sending a GET request to the server.
- The server handles that GET request (presentation layer) and then returns the page to the user.
- The user fills out the form and sends a POST request to the server.
- The server handles the POST request (presentation layer) and then sends it to the domain layer for processing.
- The domain layer executes the logic required to create a book, then tells the data layer to persist that data.
- After unrolling to the presentation layer, the server returns the appropriate response to the user, most likely a page containing a list of books and a message saying the operation was successful.
Following a classic layering architecture, a layer can only talk to the next layer in the stack—presentation talks to domain, which talks to data, and so on. The important part is that each layer must be independent and isolated to limit tight coupling.In this classic layering model, each layer should own its model. For example, the presentation layer should not send its view models to the domain layer; only domain objects should be used there. The opposite is also true: since the domain returns its own objects to the presentation layer, the presentation layer should not leak them to its consumers but organize the required information into view models or DTO instead.Here is a visual example:
Figure 14.2: Diagram representing how the layers interact with one another
Even if three is probably the most popular number of layers, we can create as many as we need; we are not limited to three layers.Let’s examine the advantages and disadvantages of classic layering, starting with the advantages:
- Knowing the purpose of a layer makes it easy to understand. For example, guessing that the data layer components read or write some data somewhere is easy.
- It creates a cohesive unit built around a single concern. For example, our data layer should not render any user interface but stick to accessing data.
- It allows us to decouple the layer from the rest of the system (the other layers). You can isolate and work within a layer with limited to no knowledge of the others. For example, suppose you are tasked with optimizing a query in a data access layer. In that case, you don’t need to know about the user interface that eventually displays that data to a user. You only need to focus on that element, optimize it, test it in isolation, and then ship the layer or redeploy the application.
- Like any other isolated unit, it should be possible to reuse a layer. For example, we could reuse our data access layer in another application that needs to query the same database for a different purpose (a different domain layer).
