Pay attention to the following aspects:

1. repositorybase <t>: iqueryable <t>
Most of you will write a repositorybase <t> by yourself when using LINQ to SQL. If you inherit iqueryable <t>, it will make your use quite comfortable.
For example:
Repository. getall (). Count (IT =>...) and repository. Count (IT => ...)
What do you like more? Of course, this is a personal liking.

2. How to determine the object status
How can we determine whether an object is new or get from a database? since there is no entitystate like the entitystate in the Entity Framework, how can we determine whether the object is written to SQL?
Test:
Directly new an object and execute oncreated ()

Get an object from the database and execute onloaded (), oncreated ()

In this way, we can make judgments on onloaded.

Public partial class entity {
Partial void onloaded (){
Isnew = false;
}

Private bool _ isnew = true;
Public bool isnew
{
Get {return _ isnew ;}
Set {_ isnew = value ;}
}
}

3. lazy load
3.1 lazy load brings us great convenience, but sometimes it also hides danger. Therefore, when writing related statements, we also need to pay attention to whether there are any optimization methods.
For example, when writing lazy load in a loop statement, should we consider whether to send SQL requests each time?
3.2 This. Product. categories. Any (IT => it...) What SQL requests will you send?

Entityset <Category> categories // is entityset <t>

Entityset <tentity>: ilist, icollection, ilist <tentity>, icollection <tentity>, ienumerable <tentity>, ienumerable, ilistsource where tentity: Class // does not implement iqueryable

Therefore, an SQL statement is sent to obtain the associated category. Call the any extension of the Set ienumerable.
Instead of sending an SQL statement about any directly.
3.3 lazy load will be cached
User. Role
User. Role
User. Role
// Call three times, but in practice, only one request is sent. Do not think that LINQ to SQL is very stupid.
　　　　

4. Load now
If there is lazy load, of course there will be immediate loading.
The immediate loading of LINQ to SQL uses loadwith <t> and associatewith <t> In dataloadoptions. This setting must be set before datacontext returns data.

Many people put datacontext In the context like me. If it is a non-Web request, it will be placed in callcontext. datacontext is unique for such a request.
 


For example:
A page in the background that retrieves the product list. Now you need to load the category immediately.

First, go to the page and perform user verification. Once the data is returned, an error occurred while setting loadwith <product> (IT => it. Category on datacontext.

Therefore, we can only move loadwith <product> (IT => it. Category) to the place where datacontext is constructed.
Although the Code is not intuitive, the performance does not seem to have any impact, and no additional SQL statements are generated. Only when the product is loaded, category is joined by inner.

Of course, when you want to take the product and do not load category, sorry, no way...

5. = NULL is not equivalent to is null
5.1
Int? Parentid = NULL;
Repositoy. Count (IT => it. parentid = parentid); // = NULL

5.2
Repositoy. Count (IT => it. Parent = NULL); // is null

The result of 1st statements is always 0. = NULL do not remember.

You can use
Repository. Count (IT => object. Equals (it. parentid, parentid ));
Or

Repository. Count (IT => parentid = NULL? It. parentid = NULL: it. parentid = parentid );