I was looking at a LINQ Query that I wrote when I was first exploring LINQ in depth at the beginning of the year.
This example was to see how to create a named anonymous type like this:
Dim query= From s In nw.Suppliers _
Order By s.CompanyName _
Select Supp = New With {s.CompanyName, s.Country, s.Products}
Looking at it today though I could not see what creating a name (Supp) for the new anonymous type was buying me in this particular case.
Its results were no different than
Dim query = From s In nw.Suppliers _
Order By s.CompanyName _
Select s.CompanyName, s.Country, s.Products
And whether I iterate through the results or bind them to a data control, there’s no still no difference.
So I wanted to make sure i was clear on when naming the anonymous type was beneficial.
One great example is in the (dog-eared by now) LINQ article that Anders Hejlsberg and Don Box wrote in February where the LINQ query results in objects with child objects. I’ve used the idea behind their couple/wife/husband example to create my own query where I combine data into new types.
For example, this query lets me create a type from some product data with a new sub-type (anonymous) of SupplierHighlights. The sub-type has only the properties Name and Country.
Dim MyQuery = From p In db.Products _
Select p.ProductName, p.QuantityPerUnit, _
SupplierHighlights = New With {.Name = p.Supplier.CompanyName, .Country = p.Supplier.Country}
Then I can access the new type and sub-type data because the subtype has a name.
For Each q In MyQuery
Console.WriteLine(“Prod Name: {0},Quantity Per Unit: {1}, Supplier: {2}, Country: {3}”, q.ProductName, q.QuantityPerUnit, q.SupplierHighlights.Name, q.SupplierHighlights.Country)
Next
Sure, I could have just created properties called SupplierName and SupplierCountry, but having the child type SupplierHighlights not only makes me more organized, but gives me the ability to do further queries if I wanted to get all of the supplier info out of the product query. This is why I am considering SupplierHighlights to be a type rather than just a property within a complex type and I should point out that I could be incorrect in calling it a type, but will stick to it until I find better evidence that it’s not. Because I have everything already grouped into a supplier type, I don’t have to list each of the fields (SupplierName, SupplierCountry), I can just query :
Dim nextQuery = From prod In query Select prod.SupplierHighlights
For Each s In nextQuery
Debug.WriteLine(s.Name, s.Country)
Next
So, here creating the named type (I really want to call it a named anonymous type. I wonder if that’s accurate?), it is really useful and necessary. Try creating the sub type without a name, and you’ll see what I mean!
Another place to leverage the named type SupplierHighlights is in databinding. I can databind directly to prod.SupplierHighlights and automatically get all of the columns. In databinding to the properties of the base query results (ProductName, QuantityPerUnit), I have to bind to “MyQuery”, so even if I had named that type, I don’t use that name anyway.
Also, take a look at this post by Paul Vick about mutable and immutable anonmyous types in VB9.
(The italicized text are a result of feedback from Bill McCarthy, who is constantly (and generously) attempting to drag me down into the depths of complexity of VB.)
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!