The key area to focus on in Figure 2 is the select clause. Here, the new keyword is used to indicate that the query results will be stored in a dynamically declared, anonymous type. This new type has two properties, upper and lower, that hold the upper and lowercase representations of the words from the supplied collection.
Creating these anonymous types on the fly really brings a whole new dimension to my interactions with the data domains. Whereas traditional mapping techniques would require me to work with canned representations of the objects returned by a query, an anonymous type gives me the freedom to construct objects of any type or shape on the fly.
These anonymous types acknowledge a reality in my environment that other object relational tools did not. Anonymous types recognize that the shape and structure of the data I want returned from a query can vary. If I have a query that accesses customers, orders, and invoices, and I want my query to return some subset of the data from these tables, I can use anonymous types to define the exact structure that will be used to represent the results of that query.
As you can imagine, this technique eliminates the need to pollute my pool of data objects with one-off, custom variants. Anonymous types allow me to create as many special representations as I need. They also eliminate the need to create a fully populated data object when I only want to access a subset of its attributes.
Of course, these anonymous types also remain true to the type-safety mantra that is a big part of the LINQ implementation. So, even though the compiler will be emitting new types to support your query, it will still fully validate them at compile time.
The power of anonymous types combined with this somewhat agnostic approach to data sources--all achieved through type-safe, language-integrated constructs-makes LINQ very intriguing. By stepping back and attacking query at the language level, I believe LINQ will create a fundamental shift in how .NET developers view the role of queries in their applications.
Even more exciting to me, though, is the fact that LINQ is just one of many efforts that are actively attempting to equip developers with better, more dynamic mechanisms for accessing data. The Rails community, for example, is also making strides in this same space. And, while none of these approaches may solve all of our problems, it's certainly encouraging to see so many mainstream tools making a real effort to move us all forward.
What influence will dynamic language constructs and integrated query concepts have on your approach to representing and accessing data in your solutions?
Join the conversation below or start a new one in the Reader Comments section.