High-performance ORM framework XLinq function details, high-performance orm framework xlinq

High-performance ORM framework XLinq function details, high-performance orm framework xlinq

I have briefly introduced some functions of XLinq, but many functions are not mentioned. Now I have added some functions to XLinq. I will introduce all the functions this time.

Design objective usage

Create TestDataContext class and User object class

Start to use

Query

LINQ:

It seems quite troublesome for the version of LINQ, so I prefer Lambda expressions in simple queries.

The code generated by the preceding statement is consistent.

Multi-Table query

The process of creating an object class is not mentioned anymore.

The two tables are connected to the query. Because the implementation with Lambda is complicated, it is not implemented with Lambda anymore.

Generated statement

Five table connection queries

Generated statement

Left join query

Because the left-side join method of linq is quite painful, there is no way for xlinq, and we will try to simplify it later.

Generated statement

Delayed Loading

Self-connection Query

Generated statement

SQL statement Query

Paging Query

Generated statement

Dynamic query

Generated statement

Query by date

This function is mainly used to address the issue that the date cannot be obtained directly in EF.

Computing days Query

Generated statement

Modify

Direct Modification

The Update clause must be written in this way to be valid.

Delete

Delete directly

Transactions

Nested transactions

Debugging support

You can view the SQL statement directly during debugging.

Multi-Database Support

Multi-database support through configuration files

Chained Api

Have you noticed that the User entity I used above has not performed any special processing, but the actually translated statement is the recognized Users table

This is actually because the EF conventions of "copy" are greater than the configuration principle. By default, the complex number of Entity names is the table name. IDs in entities are recognized as primary keys and automatically increase.

If you need to customize these rules, you need to use features or chained APIs. Now I prefer chained APIs.

You can use the chained API to configure object-related information by rewriting the ConfigurationModel method of DataContext. The table name, primary key, and primary key data sources of the User object are specified as automatic growth.

Create a table

To create a table, you must use the chained API to configure the object before automatic creation.

In addition, this function has certain limitations. This function is not enabled by default. If this function is enabled, it will automatically create a table only when there is no table in the database.

This is because the real database runtime environment may not allow automatic table creation at all, and then it is like the following. As a result, this function is not very useful, it is used only when the database is initialized for the first time.

Of course, you can also automatically create tables at all times. You need to configure a little bit. When allwayAutoCreateTables is trueWhen autoCreateTables is true, The table will always be automatically created

The following example shows how to create a Test table.

Configuration in DataContext

Table created

Custom Provider (with this function, but not tested) Performance

 

Test Results

 

 

When one query is performed, EF is slow and XLinq has a weak advantage.

In the case of N queries, EF is slow? But it is probably because of the cache, but the last figure is not very similar. Maybe it's still related to GC or something, so some people say EF is slow ··

Or is there a problem with my test code?

Insert

Test Results

Download test source code

Http://files.cnblogs.com/files/wzxinchen/XlinqDemo.zip