Entityframework-driven design practices (4)

Stored Procedure-Domain-driven anti-Pattern

Entityframework (EF) has a function that generates entity behaviors (or methods) based on the stored procedures in the database ). As I mentioned in the First blog in this series, this practice is not desirable! Because stored procedures are in the technical architecture, we are concerned with Domain Models.

Andrey yemelyanov has the following passage in his article "using ADO. Net EF in DDD: A pattern approach:

In this context, the specified ect also identifiedThe anti-pattern of using the EF (ineffective use ): The EF is used to mechanic ically derive the domain model from the database schema (database-driven approach ).Therefore, the main topic of the Guidelines shoshould be the domain-driven development with the EF and the primary focus shoshould be on how to build a conceptual model over a relational model and expose it to application programmers.

(The interviewed architect) also pointed out an "anti-pattern" for using EF ", that is, the domain model is mechanically generated by using the database structure (database-driven approach ). This proves that I am in the first articleArticle"Only the domain model can be mapped to the data model, but not the data model.

I can understand that many system-related friends like to consider database matters. After all, data storage is also an indispensable part of the software system (of course, the memory database should be different ), the database structure design directly affects the system operation efficiency. For example, adding no index or adding an index will have a significant impact on the query efficiency. However, please note: You put too much effort on the technical architecture, but the more important business architecture has been put aside.

When should I select a stored procedure? I think the operation object of a stored procedure should be data, not an object. The business layer cannot hand over the business object to the database for processing. In fact, the meaning of the stored procedure itself is to put data on the DB server for processing to reduce the number of customersProgramThe network traffic between the server and the number of round-trips, thus improving the efficiency. So,Instead of simply believing that a stored procedure can help you solve business logic problems, you can process data that is not related to the business that has a large number of queries, such as data statistics.That will only make your domain model messy. Over time, you will not be able to cope with complex business logic and demand changes.

Pay attention to the database relevance of stored procedures when selecting technologies. Stored procedures are specific to a relational database mechanism. For example, the stored procedures of SQL Server and Oracle are not universal, and some database systems do not even support stored procedures. Therefore, using stored procedures too much will cause unnecessary troubles. I personally give the following comments on whether to use the stored procedure: 1. Determine based on your needs; 2. Do not recommend using it; 3. If you need to use it for efficiency and other technical considerations, handle it as appropriate.

Looking back at the Entity Framework, although it now supports the process of generating entity methods from the database stored procedure, this is an anti-pattern, I do not want EF to provide the ability to map entity methods to stored procedures in the future, because behavior is different from data, data is state, and behavior is business, which is closely related to the domain, it should not be placed in the technical architecture "infrastructure layer.