Streamline Mapping With Orcas and LINQ
Use a pair of LINQ Technology Preview add-ins that integrate with .NET 2.0 and VS 2005 to take a look into the future of VS and data.
by Roger Jennings
November 7, 2005
Technology Toolbox: Visual Basic; C#; SQL Server 2005; XML; Cω compiler and plug-in for VS 2003 from Microsoft Research; Language Integrated Query (LINQ) Technology Previews for .NET 2.0 bits downloaded from Microsoft's LINQ Project site; VB Express, C# Express, VS 2005 Standard or higher (RTM version)
It's a good bet that 80 percent or more of today's business-oriented software projects combine general-purpose programming languages (GPPLs) and database programming languages (DBPLs).
But the ubiquity of database connectivity for Web and smart-client applications or components hasn't reduced the disconnectoften called an impedance mismatchbetween GPPLs and DBPLs. Native programming languages that generate, inspect, transform, or otherwise manipulate XML documents, such as XPath, XQuery, and XSLT (XMLPLs), currently aren't as commonly used as DBPLs but exhibit a similar mismatch to GPPLs (see the sidebar, "Cure Data Type Impedance Mismatch With LINQ"). Integration of XML Infosets as the data interchange medium in service-oriented projects is accelerating, so XMLPLs ultimately might rival the popularity of DBPLs, such as ANSI SQL, Microsoft Transact-SQL, and Oracle PL/SQL.
One fact is abundantly clear: Orcas (the code name for the next version of Visual Studio) will significantly change some aspects of how you handle and manipulate data with your applications and components. I'll give you a preview of the .NET data-management enhancements and language extensions you can expect to release with VS' forthcoming Orcas version. Most of the early programming examples for these topics and related Professional Developers Conference (PDC) 2005 sessions use C#, so I'll emphasize VB syntax where applicable.
The most important disconnect between GPPLssuch as C#, VB7+, or Javaand DBPLs or XMLPLs is the lack of a single compatible type system. Such a type system must be sufficiently flexible to accommodate the sophisticated language constructs, object orientation, inheritance, polymorphism, and other features of today's GPPLs. The type system also must support DBPLs' relational tables, SQL queries, and nullable data types; and hierarchical XML documents or fragments, elements, and attributes for XMLPLs. .NET 2.0 has three basic type systems: SQL for relational table data types; XSD for XML, XPath, XSLT, andprior to beta 2XQuery; and CLR for GPPL requirements. The ADO.NET 2.0 API bridges SQL and CLR data types; SQLXML 4.0 ties SQL to XSD; and System.Xml spans XSD and CLR. Different APIs for each data type cause developers to spend an inordinate amount of time to learn, write, debug, and rewrite brittle plumbing code. The usual culprits that break the pipes are bad SQL query strings, or XML tags or content that don't get checked until run time.
One of the goals of the Orcas release's .NET 3.0, VB 9.0, and C# 3.0 is to simplify database and XML plumbing code dramatically. Related goals are to enable the VB or C# compiler to construct and validate SQL-style queries, XPath-style operators, and XML instances or literals as first-class, CLR-compatible objects. Achieving these goals requires extending the .NET CLR type system and customizing the VB and C# compilers. The payoff for .NET developers will be increased productivity with early binding, compile-time validation, and IntelliSense for SQL-style queries, resultsets, and XML literals.
Microsoft Research's Cω (C-Omega, formerly X# and Xen) extensions to the .NET type system and C# language were the first steps to a unified type system that treats SQL-style queries, query resultsets, and XML content as full-fledged members of the .NET 1.1 CLR type system (see Additional Resources). Cω introduced the stream type, which is analogous to the .NET Framework 2.0's System.Collections.Generic.IEnumerable<T> type and contains an ordered, homogeneous set of zero or more items. You use the C# foreach statement to access all the stream's items. Cω also defined constructors for typed tuples (called anonymous structs). Anonymous structs differ from conventional C# structs as follows: Anonymous structs don't have an explicit type name; fields are ordered so you can access them from an array index; fields need not be named (but must be typed); multiple fields with the same name are allowed and return a stream when accessed by name.
Back to top