. Net enterprise-level application architecture design-data access layer

Summary

The design of the data access layer depends largely on the needs of stakeholders. For example, should the data access layer persist the object model or a set of simple values? Should the data access layer support one database or multiple databases? The following describes the common functional requirements of the data access layer.

Database independence: the data access layer is the only place in the system that knows and uses the connection string and data table name. considering this, the data access layer must depend on the Database Management System DBMS. For external observers, the data access layer should be like a black box that can be inserted into an existing system and encapsulate read and write operations for a specific DBMS.

Can be configured like a plug-in: Generally, database independence requires a set of common cross-database application programming interfaces. In our opinion, to implement true database independence, you must use the database access layer as a black box, which provides a fixed interface, and dynamically read the details of the current database access layer component from the configuration file. Another way to achieve database independence is to use the object/relationship ing tool (O/RM ). At this time, O/RM provides a set of public APIs, allowing you to switch to another database simply by modifying the configuration parameters. However, sometimes the project allows you to use O/RM, sometimes it doesn't work. (depending on the stakeholders of the project, you can understand it. It may be a biased architect, a customer who doesn't know the technology, or a soaring project manager ). We will not discuss the advantages and disadvantages of O/RM and will not stand on the team.

Object Model of persistent applications: the data access layer must be able to persist the data of applications in any form. If an object model is required, the data access layer must be able to persistently store the model in a relational structure. Of course, this will cause the notorious "Object/link impedance imbalance" problem. Relational databases actually store data tuples, while the object model constructs an object graph. Therefore, the two models naturally need to be mapped, which is also the main function of the data access layer. The object model of a persistent application is the ability to load data to a new object model and write the content of an instance back to the database. No matter what DBMS or physical table structure is selected, the persistence function should not be affected. The object model designed according to the domain model pattern does not understand the existence of the data access layer. However, if the object model is an activity record, the data access layer is embedded in all the frameworks of the implementation model.

Responsibilities of the data access layer

The data access layer has four responsibilities for users. First, the data access layer needs to persistently store data to physical storage and provide CRUD services for the external world. Second, the data access layer must also process all data-related requests it receives. The data access layer must meet transactional requirements. Finally, the data access layer also needs to properly process concurrency. From a conceptual perspective, the data access layer can be seen as a black box that encapsulates services in 4.

If the development team creates a data access layer in the project, it must fulfill these responsibilities and write code first. If you can use the O/RM tool, let the tool fulfill some responsibilities.

Data access layer and other layers

Data access layer and business layer: If you prefer relatively simple domain logic, the data access layer only contains the table adapter, which is used to query and obtain data from the DBMS, write data back to the database using stored procedures or SQL commands. For the transaction script mode, in order to satisfy the business logic, the data access layer only needs to implement pure CRUD operations. In the domain model, the data access layer is a supplement of the business layer, which is generally used by the service layer.

Data access layer and service layer: If you have a domain-driven business logic, the data access layer can be used as a tool for persistence models. The data access layer and the domain model do not communicate directly, but are coordinated by the service layer. This is also the key to the architecture.

Data access layer and performance Layer: theoretically, the data access layer cannot reach the performance layer. In the real world, the presentation layer may directly call some methods in the data access layer. The key to doing so is not that you can "speculate" to find a quick solution to a problem, more importantly, you must be aware that you are "opportunistic ". Experience tells us that if we can start from reality and properly control this kind of performance layer to call the data access layer, the results will be very good, this also adds unexpected coupling between two layers that do not want to be managed, so it can be used urgently as needed, but it should be reconstructed as soon as possible later.

Most of the final form of the data access layer depends on the architect's design on the business layer. However, to some extent, the data access layer also affects the business layer, just like the old story of having chicken or eggs first. The limitations you are subject to and your concerns determine the part from which the design begins, that is, the layer that influences the layer. In fact, there are only a few reasonable combinations between the business logic layer design and the data access layer design patterns.

Design your own data access layer

First, it is not recommended that architects and developers write a data access layer from start to end. Many applications, even enterprise-level applications, often use a strong DataSet or activity record object model, the O/RM tool provides all functions. To ensure that the database structure is completely independent, the data access layer and its users will communicate with each other using business entities (domain objects, objects in the activity record model, strong DataSet, or common data migration objects. There are many advantages in doing so. The most obvious thing is that such an application can easily support multiple data sources. The isolation interface mode also standardizes the design principle of separating data access layer interfaces and implementations. The extraction interface can simplify the test, which is a good reason. Generally speaking, the separated interface mode achieves a more hierarchical design, reducing the coupling between the data access layer and its users. This is not a bad thing.

Whether to use the Stored Procedure

1. Rumor: stored procedures are more efficient than SQL code execution: the so-called stored procedures have higher performance than normal SQL statements because of the reuse of execution plans. In other words, when a stored procedure is executed for the first time, the database generates an execution plan and then executes the code. The previous execution plan can be reused in the next execution, so the efficiency will be improved. All SQL commands require execution plans. A quote in the SQLServer2005 online document: "When SQL Server 2005 executes any SQL statement, the relational engine first checks the cache and determines whether the execution plan of the current SQL statement exists, SQL Server 2005 will reuse any executable execution plan to reduce the impact of re-compiling SQL statements on performance. If no execution plan is found, SQL Server 2005 generates a new execution plan for the current query ". From the perspective of performance, all SQL code arriving at the database will be treated equally. After compilation, there is no difference in the performance between the two.

2. Rumor: the stored procedure is safer than the SQL code: before executing any SQL statement, the database engine will try to match the authentication information provided by the caller and the access permission of the requested resource. Based on the matching results, the engine determines whether to execute the statement. In this way, stored procedures are obviously more advantageous than common SQL code in terms of security. However, security is a cross-cutting concern and should be handled from the presentation layer to the database layer. Today, role-based security is the most flexible and effective method. In the role-based security model, we have a dual security guarantee. The first is role-based security in the middle layer, and the second is to enrich the declarative security of the database engine. If you use stored procedures as the core of the entire system, you will surely make bad design decisions. You can use stored procedures, but do not use stored procedures for security purposes or logic.

3. Rumors: stored procedures can be used to block SQL injection attacks: stored procedures can certainly reduce the possibility of SQL injection, because stored procedures use strong parameters. SQL statements constructed using parameters can also block SQL injection attacks like stored procedures.

4. Rumors: stored procedures can make SQL code more stable and difficult to change: This is the product of the previous design method, that is, the database developers and other developers basically did not communicate. If you really don't rely on the physical data model, you should select the domain-driven design to design the database into a simple persistence layer.

Summary

The need for domain-driven design is followed by a more conceptual approach to operate data, and the role of the database is inevitably reduced to a persistent tool.