Blog garden modernization-[Entity Framework] specifies the returned field in the linq Query

The problem of Cross-database query of Entity Framework is solved, and the modernization of the blog Park is another step forward.

In the previous article,
The modernization of the blog Park-automapper
We have encountered an application scenario where the number of fields returned by the database query is less than the attribute of the entity class. By default, Entity Framework maps the attributes of the entity class, so we switched to automapper. Later, I pointed out in the comment that the field returned by the query can be specified through select new in LINQ. Entity Framework maps the returned field to the object class attribute.

We tried it. However, in the use of the LINQ queryCodeThe Code is as follows:

 Using  (Blogdbcontext Context  =     New  Blogdbcontext ())
{
VaR result  =  (From E  In Context. blogentries
Join t  In  Context. posttexts
On E. ID equals T. ID
  Where  E. ID  =  Entryid
Select  New  
{
Title  =  E. title,
Body  = T. Text
})
. Tolist ()
. Select (E  =>     New  Blogentry () {Title  =  E. Title, body  =  E. body })
. Firstordefault ();
}
 

This is a get by IDArticleQuery the title and content (the article content is stored in a separate database, so we need to solve the problem of cross-database query before ), from the code above, we can see that the two select statements and one tolist () statements are too long. We don't want to be so arrogant, it's really a matter of emotion. The ideal query is as follows:

 Using  (Blogdbcontext Context =     New  Blogdbcontext ())
{
VaR result  =  (From E  In  Context. blogentries
Join t  In  Context. posttexts
On E. ID equals T. ID
  Where  E. ID  =  Entryid
Select  New Blogentry ()
{
Title  =  E. title,
Body  =  T. Text
})
. Firstordefault ();
} 

However, in this case, we will face a cruel reality:

System. notsupportedexception:
The entity or complex type'Blogserver. Data. provider. blogentry' 
Cannot be constructedInA linq to entities query.
At system. Data. Objects. elinq. expressionconverter. checkinitializertype (type)
 

If a beautiful ideal meets a cruel reality, you will give up, and you will never grow. If you want to fight against the reality, even if the ideal is shattered, you must find the reason for the destruction, maybe the next ideal will become a reality.

This article is about the process of fighting against this cruel reality.

The above error message is most maddening: clearly the type is blogserver. entities. blogentry indicates the blogserver. data. provider. this type does not exist, but the namespace of the query code is blogserver. data. provider. In addition, the Code is compiled, and I do not know how the Entity Framework makes such a heterogeneous object.

The error message indicates that an exception occurs in system. Data. Objects. elinq. expressionconverter. checkinitializertype (type ).Source codeLet's look at it. Ah, we need to use reflector to dig tunnels (it is strongly required that Microsoft open the source code of Entity Framework ).

After digging the authentic information, go directly to checkinitializertype (type) and take a photo:

According to our guesses, exceptions are thrown in the highlighted part (after all, they are authentic and difficult to find. At present, we have not found any conclusive code to confirm this guess. Please forgive me ).

The code above shows that the exception is triggered under builtintypekind. entitytype or builtintypekind. complextype. Because the error message mentions "complex type", we initially locked the focus on this condition and moved around for a long time in the source code of the Entity Framework, you cannot find where to set this value.

Later, it was found that builtintypekind was not passed when an exception message was thrown, that is, "complex type" is irrelevant to builtintypekind. complextype. So we turned to builtintypekind. entitytype, and the name "entitytype" gave us an association: we registered the blogentry type in blogdbcontext. The Code is as follows:

Public ClassBlogdbcontext: dbcontext
{
PublicDbset<Blogentry>Blogentries {Get;Set;}
}
 

Maybe the problem is related to this? It is excited to discover this clue when there is no clue.

Therefore, we created a new blogentryclone with the same attributes as blogentry, and changed the code for the LINQ query:

 Using  (Blogdbcontext Context  =    New  Blogdbcontext ())
{
VaR result  =  (From E  In  Context. blogentries
Join t  In  Context. posttexts
On E. ID equals T. ID
  Where  E. ID  =  Entryid
Select  New Blogentryclone ()
{
Title  =  E. title,
Body  =  T. Text
})
. Firstordefault ();
} 

It is surprising that the operation is successful without exceptions. The guess was confirmed to be related to the blogentry registered in blogdbcontext.

After a pleasant surprise, I am confused. What should I do with this restriction? In addition, blogentryclone and blogentry cannot have any connection, and inheritance or aggregation cannot.

...

This problem and the previous cross-database query problems are confusing. When Microsoft designs the Entity Framework, it seems that it has made some assumptions out of the actual needs: If Entity Framework is used, cross-database queries are not used; If Entity Framework is used, you rarely need to specify the fields returned by the query...

Entity Framework brings us good hopes. I hope Microsoft will not let everyone's hopes fall in vain. I hope Entity Framework can be like ASP. net MVC is open (open-source), and Entity Framework can be like ASP. net MVC...