Microsoft’s Data Access Strategy

Over the last 12 months, Microsoft has been talking a lot about two major innovations related to representing and querying data. The first is the new Entity Data Model exposed as part of the ADO.NET Entity Framework, and the second is a set of extensions to the .NET Framework for integrating queries into the programming language known as LINQ. What are these technologies, how do they relate to one another, and what role do they play in Microsoft’s Data Access Strategy? Let’s start with Microsoft’s Data Access Strategy.

Does Microsoft have a Data Access Strategy?

Yes, it turns out we do. Microsoft envisions an Entity Data Platform that enables customers to define a common Entity Data Model across data services and applications. The Entity Data Platform is a multi-release vision, with future versions of reporting tools, replication, data definition, security, etc. all being built around a common Entity Data Model.

Within the .NET Framework, the ADO.NET Entity Framework is integral to this vision. The ADO.NET Entity Framework builds on our mutual investment in ADO.NET by enabling applications to write to a conceptual data model with strong notions of type, inheritance, and relationships. Through the use of “Client Views”, this conceptual model can be flexibly mapped to existing relational schemas, enabling the creation of new business structures when the underlying database schema cannot be changed and providing a level of indirection that helps isolate applications from naming as well as structural changes of the storage schema (for example, changes in the degree of storage schema normalization). The ability to work with a conceptual model greatly simplifies forms design and web service development where the underlying data store represents the model in a complex way.

Client Views are implemented within a new ADO.NET Data Provider called the Entity Client which supports an extended SQL grammar called Entity SQL (“ESQL”). ESQL provides a common query language across providers by extending the existing SQL language with constructs to work with strong notions of type, inheritance, and relationships from the Entity Data Model. By exposing the conceptual model through traditional ADO.NET Data Provider APIs (Connections, Commands, and Data Readers), existing ADO.NET programmers can immediately benefit from the conceptual model, common SQL language, and flexible mapping of the ADO.NET Entity Framework.

The ADO.NET Entity Framework also supports Object Services for building typed queries and returning, manipulating, and updating results as Business Objects. These Business Objects can be queried using ESQL, or through a new language innovation called LINQ.

What is LINQ?

Microsoft’s new Language Integrated Query (LINQ) is a set of extensions to the .NET Framework that provide common capabilities within the programming language for querying against in-memory data as well as external data sources. LINQ complements our vision for an Entity Data Platform by providing language extensions for querying data as objects within the programming language.

LINQ will ship as part of the next version of Visual Studio and the .NET Framework, codenamed Orcas. At the time that Orcas first ships, the .NET Framework will include support for LINQ over in-memory objects, LINQ over XML (XLINQ), LINQ over ADO.NET DataSets (LINQ to DataSet), and LINQ queries directly mapped to Microsoft SQL Server schemas (LINQ to SQL).

A few months after the shipment of Orcas, and within the first half of 2008, Microsoft will release the ADO.NET Entity Framework as an extension to the Orcas version of the .NET Framework. The ADO.NET Entity Framework will fully support LINQ through a feature known as “LINQ to Entities”. LINQ to Entities combines the developer experience of having query integrated into the programming language and the richness of being able to define an Entity Data Model with flexible mapping to relational stores.

What is the difference between LINQ to SQL and LINQ to Entities?

LINQ to SQL supports rapid development of applications that query Microsoft SQL Server databases using objects that map directly to SQL Server schemas. LINQ to Entities supports more flexible mapping of objects to Microsoft SQL Server and other relational databases through extended ADO.NET Data Providers.

If you are writing an application that requires any of the following features, you should use the ADO.NET Entity Framework:

· The ability to define more flexible mapping to existing relational schema, for example:

o Mapping a single class to multiple tables

o Mapping to different types of inheritance

o Directly Modeling Many to Many relationships

o Mapping to an arbitrary query against the store

· The ability to query relational stores other than the Microsoft SQL Server family of products.

· The ability to share a model across Replication, Reporting Services, BI, Integration Services, etc.

· A full textual query language

· The ability to query a conceptual model without materializing results as objects

If you do not require any of these features, LINQ to SQL may provide a simpler solution for rapid development. LINQ to SQL is targeted at rapid-development scenarios against Microsoft SQL Server and provides a simpler approach and richer design experience in the Orcas timeframe for applications with data classes that map directly to the schema of your Microsoft SQL Server database.

Microsoft is defining a migration plan for customers that start with LINQ to SQL and require additional functionality, such as richer mapping capabilities or access to other stores, to migrate to the ADO.NET Entity Framework.

Sounds great; how do I get started?

Both LINQ to SQL and the ADO.NET Entity Framework, including LINQ to Entities, are available now as part of the Orcas Beta 1. LINQ over Objects, LINQ to XML, LINQ to SQL, and LINQ to DataSet will all ship as part of the Orcas release of the .NET Framework. We will continue to ship CTPs and Betas of the ADO.NET Entity Framework that align with Orcas throughout the remainder of this year.

Mike Pizzo,
Architect, Data Programmability