Q&A
Data Driver
Microsoft's Michael Pizzo talks up Entity Framework.
With the pending release of the first Service Pack (SP) of Microsoft Visual Studio 2008 and the .NET Framework 3.5, there's a lot of buzz around the ADO.NET Entity Framework -- included in SP1 -- and Language Integrated Query (LINQ). Redmond Developer News Executive Editor Jeffrey Schwartz caught up with Michael Pizzo, Microsoft's principal architect on the Data Programmability team, after Pizzo gave a demonstration of the Entity Framework using LINQ at the DataServices World conference in New York last month.
Can you explain how LINQ and the Entity Framework interrelate?
The real difference is the Entity Model -- this idea that you can define a conceptual model that's richer than your storage model, significantly richer in terms of things that have models and can significantly differ from the schema of your storage. And now LINQ is just one thing you can do with that: the ability to program using LINQ and a console application. The second thing you can do with it is the data services I showed.
|
"You get a richer experience out-of-the-box when you work with Entity Framework than if you just used one-off LINQ implementations against X, Y or Z ..." |
Michael Pizzo, Principal Architect, Data Programmability, Microsoft |
Using LINQ?
The query aspect of the data services I showed works over any LINQ provider. However, to do updating or synchronization, or the mapping, or to do some of the more interesting things you want to do, requires that the underlying data source support more functionality. The Entity Framework will support all of that functionality, so you get a richer experience out-of-the-box when you work with Entity Framework than if you just used one-off LINQ implementations against X, Y or Z, where you have to add additional support for updating and add additional support for synchronization and add additional support for each of the other things that you're trying to do.
What's the status of synchronization now?
Synchronization is actually coming in a future version; we're not supporting synchronization in SP1 of Visual Studio 2008. It's one example of moving forward, how we plan to build more and more around this concept of Entity Models, where that Entity Model is not just something that you're writing your application or your Windows client app against, but it's something you're exposing as a data service.
So for Reporting Services in SQL Server, we'll be moving over to [the Entity Model]. Reporting Services today has its own view mechanism that allows you to define views that you can report against that differ from the schema of the database, but [that] was sort of a one-off implementation that was done for Reporting Services. We'll be migrating that to use the Entity Model. So the same models that you're defining and can write LINQ queries over you can expose as data services, you can report against, you'll be able to synchronize with in the future, and you'll be able to do more and more with.
LINQ is certainly supported by Entity Framework, and LINQ provides a great way that you can program against a data source, where Entity Framework provides one data source. LINQ is a great way to write queries in that strongly typed way that has all the type checking with everything else you have.
Implementation of LINQ is actually fairly complicated; we have two [implementations] for relational data that we've done from Microsoft, and both of them have been multiyear, multiperson efforts. Just in the prospect of doing your own LINQ implementation against a relational database, for instance, there's a fairly high level of entry, and again it doesn't get you that loose coupling, that mapping doesn't give you that design experience along with the other things that we've built around the Entity Framework.
So do you see more organizations that adopt the Entity Framework using LINQ?
The Entity Framework implements LINQ, and in my demo, I showed using LINQ against Entity Framework. We expect when you're using the Entity Framework, and writing applications against the Entity Framework, LINQ will be the primary way that you do that. But LINQ itself is a technology that allows you to write strongly typed queries over any LINQ provider, of which we have four shipping as of Visual Studio 2008 SP1. As part of Visual Studio, we have one that's an implementation specifically over SQL Server schema, thus LINQ to SQL; one that's LINQ over XML data, or LINQ to XML; one that's LINQ over your collection of objects, which is LINQ to Objects; and now we will have LINQ to Entities, which is what I showed -- the LINQ implementation over Entities.
In addition, a number of third parties are coming out with LINQ implementations of their own. For example, there's LINQ to Amazon. Actually, there's also -- with ADO.NET Data Services -- you can access that data service in a common REST manner, just using HTTP through the browser. But we built a client-side library that allows you to build objects that represent your results and build queries in terms of those objects using LINQ. There's actually another implementation of LINQ that allows you to -- on Silverlight or a .NET client -- write your LINQ queries that query through that ADO.NET Data Service against the Entity Framework, or whatever LINQ implementation you have sitting under the ADO.NET Data Service.
So LINQ is really a programming pattern. It's a language-integrated feature and a runtime feature that work together to provide you this strongly typed query-building experience. But now there has to be an implementation of that i-queryable provider implementation that takes the LINQ expression and actually translates it to SQL if it's going against a SQL database; translates it to XQuery if you're going to XML. If you're doing [LINQ] against the REST interface, it translates it to that REST interface.
And Entity Framework is still targeted for year-end?
It will be this year.
A later release will have synchronization support?
In a future release we'll add the ability to synchronize in terms of an Entity Model, to do reporting in terms of an Entity Model; and you can imagine us bringing in more and more features, all in terms of this common model, to do data management, where you distribute data and access it in terms of a common model. We'll build quite a bit on top of this.
What's the timing on that?
It will be a future release of Visual Studio and the .NET Framework. You can imagine that each implementation will have more and more built around the Entity Framework and for SQL Server services like Reporting Services. It will be a future version of SQL Server that has additional services built around the Entity Model.
What's your reaction to the open letter, "Vote of No Confidence," in the Entity Framework that was posted on June 23?
Many of the points they bring up are well-known points that we've been discussing with the various, very vocal communities within the object relational mapping space. I know in particular we've been talking to the persistence ignorance [proponents] since the MVP conference last year about their concerns. We understand their perspective and plan on providing more persistence and inheritance support in the next release.
What subset of the dev community does this complaint represent?
The concerns we've heard in the past have been from a very vocal subgroup of the people who are intended to be consuming the Entity Framework. While we certainly take them seriously, as I said, and are planning on addressing many of their concerns -- specifically around persistence ignorance in the next release -- we certainly see value in the large number of customers who see value in the Entity Framework as it is in version 1.
[Microsoft Product Manager Tim Mallalieu posted a detailed response to the vote of no confidence
here. --Ed.]
About the Author
Jeffrey Schwartz is editor of Redmond magazine and also covers cloud computing for Virtualization Review's Cloud Report. In addition, he writes the Channeling the Cloud column for Redmond Channel Partner. Follow him on Twitter @JeffreySchwartz.