Where the DAL Fits Into the Three-Layer Architecture
In .NET development, the Data Access Layer (DAL) establishes communications between an application's database and business logic. It's the foundational component of a three-layer architecture, which .NET developers (including our own!) leverage to construct services and web applications.
Depending on the tools at their disposal, developers can exercise control over the DAL, its complexity and performance characteristics. In order to understand the implications of selecting DAL patterns, let's take a look at DAL's position within the three-layer architecture.
The three-layer architecture (as its name suggests) separates logical components into three groups:
- The Presentation layer determines how the application interacts with the user. In the case of a visual application, it defines the layout, navigation, visual data elements, user inputs and interactions and visual design. Essentially, it controls how the user interacts with data, while enforcing the application's logical rules. In the case of a service application, the presentation layer is responsible for formatting the data to be delivered to the caller, and accepting data to be processed. Overall, the presentation layer is the component which interacts with the BLL, as it permits data entry and manipulation and presentation. Although the business logic is hosted in the BLL, some logic, such as validation can live in the presentation layer to deliver a more responsive application and a better user experience.
- The Business Logic layer (BLL) comprises the application's core functions, which retrieve, process, transform and store the data it receives by interacting with the Presentation and Data Access layers. This layer also enforces data quality standards through custom functions, but this responsibility may fall on the DAL depending on the pattern your developer chooses. As a whole, the BLL provides the components, agents, entities and interfaces the Presentation layer requires to drive user requests. In their book “Business Component Factory,” Peter Herzum and Oliver Sims provided a good example of how a BLL component supports application function: A component is a software equivalent of a business process, and is meant to work “as an autonomous, reusable element.”
- The Data Access layer (DAL) dictates how the business logic interacts with SQL databases, NoSQLdatabases, local or cloud file stores and other forms of persistent storage by using data access components and utilities responsible for establishing the contract to storage. The purpose of the DAL is to convert data between the format in which it resides in the storage medium to the format expected by the BLL for both retrieval and persistence activities. How the data access components interact with persistent storage depends on the DAL pattern developers implement.
Let's focus on the DAL's data access component. By Microsoft's definition, these assets "abstract the logic required to access the underlying data stores." Depending on the BLL's demands, a DAL pattern may convert data into objects or provide the BLL with a static repository service the BLL may call when retrieving data. Some data access frameworks, including the Entity Framework, provide object-relational mapping, reducing the amount of data-access code developers have to write from scratch.
How the DAL supplies data to business-layer functions partly depends on the pattern a development team utilizes. In some cases, the BLL is given partial control of data materialization via deferred methods. Eager materialization, on the other hand involves converting data into objects before it leaves the DAL.
How the DAL interacts with the BLL depends on the demands of your application, the development resources at your disposal and the project’s timeline.