Finding the Missing LINQ



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.


About the author

Tod Golding's picture Tod Golding

Tod Golding is the founder of Blue Puma Software, a technical consulting company that provides software training, mentoring, and development services. He has twenty years of experience as a software developer, lead architect, and development manager for organizations engaged in the delivery of large-scale commercial and internal solutions. Tod has an extensive background leveraging .NET, J2EE, and Windows DNA technologies, which has allowed him to become equally skilled with C#, Java, and C++. He has worked and consulted at a variety of companies, including stints with Microsoft and Borland. Tod is the author of Professional .NET 2.0 Generics and a contributing author for the XML Programming Bible. Tod can be contacted at

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!