Daniel Simmons on ADO.NET Entity Framework 4

Developer productivity improvements are on the horizon for the next version of Entity Framework

Editor’s note: Welcome to .NETRocks Conversations, excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 571, with guest Daniel Simmons, development manager for Microsoft's Entity Framework team, on Entity Framework 4.

Carl Franklin: Daniel Simmons is here with us. We are talking about Entity Framework. So what's new since the last time we talked?

Daniel Simmons: Well, you know, the big thing is that we shipped Entity Framework 4.0.

Richard Campbell: So what's your role for EF now?

DS: Well, you know, the EF team is part of this data and modeling group, which is in charge of WCF, data services, Entity Framework, and also things like IM and a whole variety of products. I'm one of the architects kind of in a larger data and modeling group, but I'm really the one that focuses on the Entity Framework.

RC: So you obviously are the man to ask about the architectures around the next version of Entity Framework.

DS: Yeah. Well, a lot of the architecture of the big picture has been set in place over the past couple of releases, but what we're really focusing in the next kind-of release is on continuing to just improve developer productivity, continuing to improve the reach of the product out into all different kinds of features that the databases support, and those kinds of things. …We started releasing these future CTPs to get some early look at features that we knew weren't going to make it into .NET 4.0 but that we wanted to get feedback on and continue developing for the next chance we could have to release them.

RC: I guess the challenge now that you're sort of in the box is, are you really not going to ship a version of Entity Framework until the next version of Studio in .NET? Well, that's at least two years out.

DS: Well, it is a challenge, and it is something that we're spending a lot of time thinking about and working on. Not only do we have the desire to get things out to folks more frequently than that, but also we really have two different kinds of ship vehicles that we're interested in, and one of them is about Visual Studio in .NET, and one of them is about SQL Server. You know, while Entity Framework definitely supports a variety of databases, there's no apologies for the fact that we want SQL Server to be the best experience. That's the product that pays the bills.

RC: Right.

DS: So we're really working on ways to make sure that we ship both with VS and with SQL, so that the moment the SQL Server comes out there's a great product, great way to use SQL Server features in Entity Framework. There are some interesting logistics. I think at a minimum, we're going to look at ways to ship with SQL Server, and we may even try and scheme some ways to ship even a little more frequently than that, but I can't really tell for sure if that's going to work out yet.

RC: So right off the bat, I got to think there was—and obviously you've already alluded to this with the CTPs that are post EF 4.0—there's a bunch of features that didn't make the cut to be in .NET 4.0 in that incarnation, and so we've already have a pretty good picture of what's in "EF 5.0." Is there other big thinking going on of major ships to come in EF 5.0?

DS: Well, probably one of the biggest things that will kind of show up on the surface and people will see right away is that we've been working on ways to make developers a whole lot more productive. Using the Entity Framework, how can I... you know, what's the absolute least number of characters I have to type? How can it be the least number of concepts I have to understand and easiest to get started? Those kinds of things, and that's really a part of where the CTP has been focused. Not so much necessarily on the features per se. You know, there's the obvious set of things like adding eNums or multiple results from stored procedure, or different kinds of things....

RC: Right.

DS: But really trying to kind of create a speed dial, if you will, so there's a quick path into getting started and using the Entity Framework. You know, we have this EF design log where we post things as we're doing design work and before things are released. Just in the last week or two, we made a post there about this next round of productivity improvements. It really ends up being a pretty different experience. You know, we want to support people who have a database, and they want to reverse engineer from a database and get going. We also want to support people who want to use the graphical design tool and build the model and have it create a database and create some code from you.

RC: Right.

DS: But these productivity improvements are really especially great for another class of users who say, "I just want to write my classes like it's my code, let me write it," and then you just handle the saving part.

RC: Yeah. And at times I'm going to put stuff away and I when I ask for it back, I'd like it back.

DS: That's right. And so with this next round of improvements and in the CTP, you can just take standard POCO classes. They really don't have to have anything special about them at all except some idea of a property that represents the unique key for that.

RC: Right.

CF: So Dan Cornelia who's listening out there has a question. Is LINQ to SQL truly end of the line?

DS: You know, this is the question we always get, and I have to give sort of the standard two-part answer—which is, on the one hand, absolutely not in the sense that it's part of the framework. We're not taking it out of the framework.

CF: Right.

DS: No more than Win Forms is out of the framework. Lots of people are still writing Win Forms apps, but at the same time we're not putting a lot of energy into making better Win Forms, and by the same token we're not putting into a lot of energy into making better, fancier LINQ to SQL. The energy is going into the Entity Framework.

CF: Yeah, the innovation is happening in the app.

DS: That's right.

CF: So if you've got existing LINQ to SQL code, there's no need to—well, at least there's no need for fear of losing it to port it to EF, but if you're going to be doing new development, you want to be using EF.

DS: Yeah, yeah. That's really what I would recommend. I mean, we're going to continue to support LINQ to SQL in all the different ways that support comes out in the Product Support Services as well as making sure that it works with new versions of the framework in SQL Server and those kinds of things. But if you start a new project, it's really becoming more and more clear that the Entity Framework is a good choice both because increasingly it does everything that LINQ to SQL did and it's getting as easier to use and because we continue to innovate and add new functionality there.


RC: I guess the question still is, I mean, folks like LINQ to SQL because it was so simple. Are you feeling like you're headed toward a simplicity level with Entity Framework?

DS: I really do. I honestly—you know, one of the guys that we spent a lot of time working with even though he is not in our organization is Scott Guthrie.

RC: Right.

DS: Because he's really plugged into a lot of folks, talks to a lot of customers, and has a pretty good pipeline of feedback for us. So as we're working on this last round of productivity improvements, we did a number of reviews with him, and he has written applications using LINQ to SQL and started writing them using Entity Framework and how do we compare that. I really think with this next round of improvements, it's going to be simpler than using LINQ to SQL, easier to get started, easier to understand what's going on.
And yet there's a smooth wrap to using the more advanced functionalities that the EF has rather than having to completely port your app and change to a different technology once you hit the wall of what something like LINQ to SQL could do, and that's really the goal.

RC: Yeah. Does that mean actually a migration path to LINQ to SQL folks? Or just making it so that why would you even look there, this is the simplest way to go?

DS: Well, you know, last summer we had an intern come work on the team focused on migrating, providing guidance, and starting to write some tools for migrating applications from LINQ to SQL to the Entity Framework, and we made some progress in that direction. But the truth is every time we sit down and think about how we want to allocate resources, the analysis comes up we're better off adding new functionality that makes it easier to use the Entity Framework, makes your code that you wrote really to SQL just work with the Entity Framework without as much change, rather than trying to build some kind of auto-porting to modify your code tool or something like that.

There's much more! Listen to or read the full interview at www.dotnetrocks.com.

Richard Campbell and Carl Franklin (both Microsoft Regional Directors) are the voices and brains behind .NET Rocks! (www.dotnetrocks.com). They interview experts to bring you insights into .NET technology and the state of software development. They’re more than dry technical interviewers—they have fun!

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.