Dream of becoming a reality: enitity framework provides an ideal way to query specified fields

In the previous article "blog garden modernization-[Entity Framework] specifying returned fields in the LINQ query", we found the cause of the problem, but did not find a solution.

We are still in love with the ideal solution. Although many attempts failed, we believe thatCodeEverything in the world is possible.

Let's first review the ideal LINQ query code:

 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 ();
} 

Review the error message:

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)
 

There is also blogdbcontext code:

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

Link the three to streamline the problem: if a type (blogentry here) is registered to dbset <t>, enity framework considers this type as complex type, an exception is thrown when you select new. Create a type with the same attributes (blogentryclone in the previous article), because it is not registered to dbset <t>, no exception is thrown.

Originally, a simple blogentry, from dbset <t> to enity framework, becomes complicated. However, it is still simple to access from other places. Obviously, dbset <t> has a problem.

You can guess that dbset has moved blogentry, which may be because the type information of blogentry is modified...

Therefore, dbset <t> and select new must use different types and share attribute information.

Naturally, we will think of inheritance, So we created a class derivedblogentry inherited from blogentry. The Code is as follows:

 
Public ClassDerivedblogentry: blogentry
{
}
 

Then, use it for select new. The 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  Derivedblogentry ()
{
Title  =  E. title,
Body  = T. Text
}
). Firstordefault ();
} 

The same complex type error is returned.

After a brief analysis, you can understand why this error occurs. Because dbset <t> changes the type of blogentry, derivedblogentry inherits from blogentry, which is naturally affected.

Further refine the problem to be solved: The type (blogentry1) in dbset <t> and the type (blogentry2) in select new must share the attribute (which must be associated ), the modification to the blogentry1 type does not affect blogentry2.

Although the parent class can share attributes with the subclass, modifications to the parent class type will inevitably subclass, which is the case above.

It seems that we cannot find a solution after breaking our shoes...

If you change the position used by the parent class and the subclass, that is, use derivedblogentry in dbset <t> and use blogentry in select new...

When this idea flashed, I felt that this was the solution. At that time, I was so excited that I could not wait to use the code for verification. The Code is as follows:

Blogdbcontext code:

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

Code for querying the data using LINQ:

 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 ();
} 

When the code test passed, the wonderful feeling in my heart could not be expressed in words... at that time I really wanted to celebrate, so I wrote this blog as a celebration!