About the limitations of LINQ to SQL

The first two weeks, due to the needs of the project, calm down and read the pro. LINQ. language. integrated. query. in. in csharp.2008, we hope to apply LINQ to SQL to our projects. After reading this article, I have some experiences and deep feelings about the limitations of writing to SQL.

I will not discuss the basic syntax of LINQ or how to use LINQ to SQL to perform siud operations on the database.Article, There are already a lot on the Internet. Here we will focus on the shortcomings of LINQ to SQL.

Less than 1: the rules are too dead and less scalable.
The rules mentioned here are too dead. They mainly refer to the binding between entities at the business layer and database tables. Basically, only one object corresponds to one table, and there are too many requirements on the object, for example, (1) the object must have a default constructor without parameters (if not, the object will be compiled but cannot be run, because the object is constructed by reflection in LINQ to SQL, in addition, it uses the non-parametric constructor of the object); (2) All object storage fields of the object cannot have the readonly keyword (reflection needs to write the value of this field ); (3) If the object has a list of child objects (Object objects with multiple links), the list must be of the entityset <t> type; (4) If the object has a reference to the parent object (the object on the "one" side of the "one-to-many" relationship), the application type must be entityref <t>, in addition, fields such as the primary key of the parent object must exist. All these rules mean that the entity objects at the business layer cannot be manually written for customization and extension. Some people have said that you didn't have to write your hand. sqlmetal and visual design tools exist, and you have to write your hand. I agree that these tools are really useful, but do the entities generated by these tools meet our business needs? Because of the diversity of business changes, too many rules and regulations have greatly bound our hands and feet.

Less than 2: does not support timespan
It is incredible that the timespan field of the object class cannot be directly mapped to the SQL Server column (maybe I didn't find the correct method. If you have a solution, please be advised ). What should I do? Is it necessary to make changes. There are many flexible methods, but such basic types can be implemented only after they are changed. Is this a mature enough powerful framework to show to you?

3: poor transparency and difficulties in use
I wrote this before reading a book. Code , As follows:
Using ( Programconsoledatacontext DB = New Programconsoledatacontext ())
{
Basetask Basetask = New Basetask ()
{
Name = "jhh ",
};

DB. basetasks. Attach (basetask );
DB. submitchanges ();
}
The result failed to run. Of course, I know why it failed now, but this also exposes the problem that the user must understand the internal operation mode of the datacontext object when using LINQ to SQL. The "insertonsubmit" and "deleteonsubmit" methods in Table <t> are sufficient to indicate that they are not encapsulated. In fact, "insertonsubmit" was originally designed as "add", and "deleteonsubmit" was originally named "Remove". Do you like the following name or the previous name, do you like the subsequent encapsulation or the previous one? It is estimated that the original goal of the LINQ to SQL design team is to provide a more encapsulated framework, but it is not implemented for various reasons, so it is second to none, but I am afraid that you may misunderstand the "add" and "Remove" methods, so I changed it to the current name to emphasize the concept of "Submit" (purely personal speculation ).
The entity change tracking function provided by datacontext is a major highlight, but it is not very convenient to use. Maybe I did not find a good application mode. I was thinking, should I save a reference of this object permanently, or should I create an object once. If the first method is used Program Load more and more data as the running time increases. In the end, the whole database may be loaded. If the second method is used, so how can I use the entity change tracking feature provided by it? Of course, you can use the attach method of table <t>, but I do not know the updatemode method every time. What if I want to attach this object to be a large object, there are a lot of entitysets hanging below. How can I attach them? I thought for a long time and did not find the answer.

4: performance problems
This is not to mention. If reflection is used to achieve this, of course there is a loss and it can be accepted. Is there any loss of performance for the current Orm? Therefore, this can be said to be a problem, or it can be said that it is not a problem, and everyone can understand it. However, the implementation of datacontext object change tracking is in exchange for performance and space. If you don't believe it, try retrieve an object in datacontext and change the object. How many times have your object constructor been called? Twice? Why? Because the retrieve operation changes the object again, because datacontext saves the original copy of the object. Originally, I heard that after inotifypropertychanging and inotifypropertychanged interfaces are implemented in an object, datacontext can track object changes based on the functions provided by this interface. I think, in this way, I won't create a copy. I found that I still created a copy. Why? I don't know.

I have not done any projects with LINQ to SQL, so these ideas may not be very mature. As a matter of fact, I think the orientation of LINQ to SQL is not intended for enterprise-level applications, and we should not have too many requirements on it. In fact, simplicity is its biggest beauty. I think it is suitable for some simple projects with complex business logic, but not for large projects. I even think it is not suitable for medium-sized projects. Currently, the ado.net Entity Framework has been bate3, and we are looking forward to the surprise of its LINQ to entities.

Finally, I raised a question: is Orm really promising? Can large-scale projects use Orm? When will there be a mature object-oriented database product, or will it never be because of the beauty of the relational model in mathematics?