. Net open-source lightweight ORM framework Dapper extension Series 4 (Reconstruction and optimization)

After the expansion of the first three series, all functions have been implemented. However, a lot of deficiencies are also exposed, mainly because the code is messy and some parts are processed repeatedly. More importantly, the performance is poor. Let's start from these two aspects today and try to solve these problems as much as possible. The main content of code optimization is as follows: 1. The reason why the transaction is encapsulated in the extension is canceled: if the transaction is encapsulated in the extension, the flexibility of the transaction processing will be lost. 2. migrate all SQL assembly to the SqlQuery class to make the code clearer: View Code3. the extended class only has simple calls, and there is no complicated logic DapperEx: for more details about View Code, see the source Code provided at the end of the article. Performance Optimization in the first three series of extensions, I don't know if anyone is going to test the performance. I tested it and the results won't be released. Anyway, I just want to say that the performance is "very poor ", especially for repeated queries, the performance is poor. The main content is as follows: 1. added an object description class to save the reflected entities (ModelDes): View Code2. added a static cache to save the reflected entities, directly retrieve from the cache: // <summary> /// used to convert the object into a cache object // </summary> private static Dictionary <string, modelDes> _ ModelDesCache = new Dictionary <string, ModelDes> (); the cache operation mainly uses the following methods: the View Code is relatively large, and the previous Common class basically overwrites the Code. 3. SqlQuery generates a parameter class that is extremely performance-consuming, that is, dynamic generation of parameter classes. The cache is also added here (the difference between the above and the above ). // Dynamic parameter class cache protected static Dictionary <string, Type> DynamicParamModelCache = new Dictionary <string, Type> (); specific processing Code: View Code is being optimized due to the previous Code, I have specially processed the parameters. Here, the table name and parameter name are combined into a cache KEY. When the KEY matches, as long as the current request parameter set is compared with the existing KEY conversion in the parameter set, as long as it is a subset of the existing KEY, it indicates that the cache exists. For example, the cache contains a cache whose key is "account_Id1_CreateTime1_CreateTime2". When a new SQL statement is executed, the combined key is "account_Id1_CreateTime1 ", the subsequent KEY is the subset of the previous KEY, and the parameter object is cached with the existing key: "account_Id1_CreateTime1_CreateTime2. For more information, see the source code. In the performance test, we will compare the performance of the optimized Dapper and the native Dapper to see if the performance difference is great. Below, we will pass the 500 cycles, each cycle carries out 100 repeated queries or add or delete operations. The following is the comparison result of 5 times: the performance comparison is better than that of native Dapper in terms of performance, each 100 data insertion and deletion operations have a difference of 3-4 milliseconds, and the query latency is a little bit different. If the latency is 7-8 milliseconds, the latency is only 0.0 milliseconds. Through performance comparison, the operation time is very low, completely within the acceptable range. Our dapper extension series has come to an end. Thank you. Note: Please confirm if there are any errors or exceptions in the program. Thank you!