Programming Microsoft ASP.NET 4 - Dino Esposito [311]
Implementation of a DAL
Until recently, the DAL was just fused to the BLL and limited to a superset of the ADO.NET library created for the purpose of making writing data access code easier. In other words, for many years of the .NET era, the DAL has been simply a layer of helper methods to write data access quickly.
The shift toward a more conceptual view of the problem’s domain, and subsequently the advent of the Domain Model pattern, brought new interest in the role of the DAL. Now that you have a domain model exposed as the real database in the application’s eyes, you really need a distinct and well-defined layer that bridges the gap between the domain model and storage.
Although the role of the DAL is still the same as it was 20 years ago, the technologies are different, as is the approach to it taken by architects and developers. It’s interesting to briefly review the inner nature of the DAL in light of the pattern used for the BLL.
DAL and the Table Module Pattern
Having a BLL organized in table module classes leads you to having a database-centric vision of the system. Every operation you orchestrate in the application logic is immediately resolved in terms of database operations. It’s natural, at this point, to create an in-memory representation of data that closely reflects the structure of the underlying tables.
With the Table Module pattern, you have table classes and methods to indicate query or update operations. Any data being exchanged is expressed through ADO.NET container types such as DataSet and DataTable. Any data access logic is implemented through ADO.NET commands or batch updates.
The DAL still has the role of persisting data to databases, but data is stored in database-like structures (for example, DataSet), and a system framework (for example, ADO.NET) offers great support for working with DataSet types. As a result, BLL and DAL are merged together and are rather indistinguishable. The DAL, when physically distinct from BLL and living in its own assembly, is nothing more than a library of helper methods.
DAL and the Active Record Pattern
An Active Record BLL makes domain data available in the form of objects with a close resemblance to records of database tables. You no longer deal with super-array types such as DataSet, but instead have an object model to map to table records.
The DAL, therefore, has a clearer role here. It exists to bridge the gap between entities in the object model and database tables. The mapping work required from the DAL is relatively simple because there’s not much abstraction to cope with. Mapping between object properties and table columns is neat and well defined; the storage is a relational database.
The benefit of using Active Record instead of Table Module is mostly in the fact that an Active Record object model can be created to be a real strongly typed counterpart of a table. In this regard, it fits better than a generic container such as DataSets and can be extended at will. The drawback is in the extra work required to create the model, but fortunately many tools exist to infer the model directly from tables.
DAL and the Domain Model Pattern
According to the Domain Model pattern, you create from the ground up an entity model with any appropriate relationships. More importantly, you do so while being completely ignorant about persistence. First, you create the object model that best represents the business domain; second, you think of how to persist it. As odd as it might sound, in a Domain Model scenario the database is purely part of the infrastructure. (See Figure 14-6.)
Figure 14-6. The DAL is just part of the infrastructure.
A DAL has four main responsibilities toward its consumers. In the first place, a DAL persists data to the physical storage and supplies CRUD services to the outside world. Second, the DAL is responsible for servicing any queries for data it receives. Finally, a DAL must be able to provide transactional semantics and handle concurrency properly. Conceptually, the DAL is a sort of