Entity Framework 4 in action Reading Notes-Chapter 4: querying using LINQ to entities: inherited Query

Inherited introduces the concept of multi-state query. For this type of query, the inheritance hierarchy and returned objects may be of different types, but inherited from the same base class.

Suppose you want to query all products. The list of product objects is obtained from the polymorphism query, but the specific type is shirt or shoe, because the engine automatically instantiates to the correct type. You can not only automatically obtain the correct type, but also filter by type application. For example, you can query only the shoes or shirts.

Our beloved beta testing users are finally satisfied with the presentation of orderit orders, and now users want to focus on the product. First, they want to view all products on a single page. This is very simple:

 
VaRResult =FromPInCTX. ProductsSelectP;
 

This sectionCodeThe result is a list of product objects, but the actual type is its specific inheritance class.

Next, you want to filter the application based on the product type. LINQ provides two methods to specify the type: the equal type operator (is) and the oftype method. There is an important difference between the two methods. The equal operator performs the filter operation. However, the oftype <t> method not only filters, but also converts it to the type to be queried. The following code is clearer:

Ienumerable<Product> Products =FromPInCTX. ProductsWherePIsShoeSelectP;Ienumerable<Shoe> Shoes =FromPInCTX. Products. oftype <Shoe> ()SelectP;
 

Because of this tiny difference, it is entirely a personal problem to choose which method. Suppose you have several product types, and you need to find the only shoes and shirts.

In this example, using oftype <t> is possible, but it is too complicated, because you must combine two queries to retrieve different objects. Before merging results, you must convert the internal object to the product base class. In contrast, the equality operator does not need to modify the final result, so you do not need to do additional work after filtering.

In other cases, you may want to search for only one specific product. In this case, using the oftype <t> method is the best choice.

You can filter the attributes of the base class in the same way. You want to filter data of the inherited type. For example, you need all the sport attributes that contain the basket shoes. This is another scenario where oftype <t> is applied. Because oftype <t> converts data, the where method (after the oftype <t> method) knows that the output type is shoe, so this search is very simple:

 
VaRResult =FromPInCTX. Products. oftype <Shoe> ()WhereP. Sport ="Basket"SelectP;
 

But what if you want to find all the "basket" shoes and return the product object in the form of a list? In this case, the previous Code does not work because it returns the list of shoe objects. There are two solutions: Use the cast <t> method of LINQ to convert it back to the product, or convert the object to the desired type in the WHERE clause, and then apply the filter. Second, display conversion cannot be used, which causes a running exception. You must use the as conversion operator.

The first code:

VaRResult =FromPInCTX. ProductsWhere(PAsShoe). Sport ="Basket"SelectP;
 

Code 2:

 
VaRResult = (FromPInCTX. Products. oftype <Shoe> ()WhereP. Sport ="Basket"SelectP). Cast <Product> ();
 

In the first method, the required type is product. Therefore, all products are scanned, but only "basket" shoes are returned. The generated SQL statement also follows the same path: It scans all product, shoe, and shirt tables, and uses the select case SQL clause to identify whether a row is shoe or shirt, which wastes a lot of resources, because you do not need to obtain data from the shirt table.

The second method, because it directly specifies that the required type is shoe, the generated SQL only uses the product and shoe tables, and optimizes the query performance. Unless you have powerful motivation to use conversion in where, you 'd better always use the oftype <t> method.

Another performance note should be kept in mind. Consider the following code:

 
VaRResult =FromPInCTX. ProductsSelectP. Name;
 

The unique column involved is the name in the product table. You may expect the generated SQL statement to query only the table. However, the SQL statements are connected to the external tables involved in the hierarchy (shirt and shoe. In this case, the stored procedure is the best method.

So far, you have used the standard LINQ method. They are powerful, but they do not include all query possibilities. LINQ to entities allows you to apply any CLR method, but the SQL conversion engine cannot understand everything. More importantly, you may have a database function or a user-defined function that is useful in the query of the LINQ to entities, but there is no way to use these functions. This is where ef4.0 functions play a role.