"Anatomy PetShop" Series II: PetShop data Access layer database access design

In series one, I analyze the architecture design of petshop as a whole, and mention the concept of layering. Starting with this section, I will analyze the layers in sequence, in order to get a more detailed and in-depth understanding. In PetShop 4.0, due to the introduction of some of the new features of ASP.net 2.0, the content of the data layer is also more extensive and complex, including: Database access, messaging, membership, profile four parts. In series two, I'll describe the design for database access.

In PetShop, the database objects that the system needs to deal with are divided into two types: one is the data entity and the corresponding data table in the corresponding database. They have no behavior and are used only to represent the data of the object. These entity classes are placed in the model assembly, such as the entity class OrderInfo for the order of the datasheet, whose class diagram is as follows:

These objects do not have a persistent function, simply, they are as a carrier of data, so that business logic for the corresponding data tables for read/write operations. Although the properties of these classes map the columns of the datasheet, and each instance of the object corresponds exactly to each row of the datasheet, these entity classes do not have the corresponding database access capabilities.

Because the data access layer and the business logic layer will operate on these data entities, the assembly model is referenced by the modules in the two tiers.

The second type of database object is the business logic object of the data. The business logic referred to here is not a domain (domain) business logic in the sense of the business logic (in this sense, I prefer to refer to the business logic layer as "domain Logic Layer"), in general, these business logic is basic database operations, including Select,insert, Update and delete. Because these business logic objects have only behavior and are not data-independent, they are abstracted as a separate interface module Idal, such as the interface for a datasheet order Iorder: