NETRocks Conversations: Chris Sells on Entity Framework and More

Editor’s note:

Welcome to “.NET Rocks 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 excerpt is from show 511, “Chris Sells Live in Boston.” This interview took place in front of a live audience on the three-week 15-city .NET Rocks and Visual Studio 2010 Road Trip.

Carl Franklin: What are you writing these days at Microsoft?

Chris Sells: I do a variety of things. I do a bunch of community work for the data and modeling group inside the SQL Server division. You guys have heard about M and Quadrant. I do a bunch of that. I also work with Entity Framework, OData, and Data Services. I have a book called “Programming Data” from Addison-Wesley where I look at the set of data technologies across all of the SQL Server division. I'm busy building real-world apps with these technologies—figuring out how they all fit together, and when to use them, and when not to use them, and how to use them.

Franklin: There doesn't seem to be a lot of guidance overall like you're talking about.

Sells: Well, there's a book on Entity Framework. And you could expect a book on OData, and you have books on Integration Services and Reporting Services, Analysis Services, and you can expect to see books on M and Quadrant—those kinds of books. But what you don't see a lot of, and this is where I really felt the need, was you've got this set of technologies: how are they supposed to be used together? It's not like the teams got together and said “How do we make this stuff work on one big seamless thing?”

Richard Campbell: Right.

Sells: My corporate masters allowed me to do this work because I say, “I'm going to use all these features.” My pet project is I'm rebuilding sellsbrothers.com, which is a 15-year-old website. A gazillion people go there. It has all kinds of features. I'm taking our newest and latest data technologies that we recommend people use, OData, Entity Framework, Integration Services, and Reporting Services, those technologies, and I'm rebuilding the website from scratch using the latest and greatest .NET 4.0 web technologies, MVC 2.0, and IIS and all of those things.

Franklin: These technologies don't necessarily overlap. OData is a protocol much like RSS or Atom, but Entity Framework contains a data model and then software for accessing that data model.

Sells: It's less about the overlap. There's definitely a story that we're working hard to tell. Across all of the.NET programming technologies for data on the platform, you can go right now to msdn.com/data and you can see that story. I'm busy doing two things. One, I'm writing the book. The other is I'm expanding these sets of technologies across the SQL Server division and in fact across Microsoft. What kind of applications do you guys build? Do you build websites, people? Yeah. People raising their hands.

Campbell: About a third?

Sells: It seems like most people that I've talked to are building websites. Those people who are building websites keep their stuff in the database. So between ASP.NET and Entity Framework and SQL Server, that is a broad range of the applications people are actually building today on the Microsoft platform. They're doing it without much guidance. I'm building without guidance myself. I'm building my own website. So I'm trying to write it down, and then in the process, I've got a big list of things that don't work the way I think they ought to. I'm busy going to the individual teams and saying, "Well, when our users use this technology with this technology here, it doesn't work. This is why, and here is what I'd like to do." The idea is to drive it to be even better in the future, which is why my bosses let me do it.

Franklin: So if we went down this list of technologies, could you drop us some hints about when it's appropriate to use them? Can we actually go there?

Sells: Absolutely. I'm happy to.

Franklin: All right. Let's start with Entity Framework.

Sells: Entity Framework is downright easy actually. The Entity Framework is, “Hey, I've got a database and I'd like to write some code against it.” That's one scenario. You point the Wizard from Visual Studio at your database. You pick and choose the tables and the stored procedures and reviews that you want to use in your application, and you get a C# or VB programming model. Once you've done that, you get the raw view: Here's how it looks in the database. Now as an example, the database on sellsbrothers.com was built by—well, actually the tables have been built up over time by different people. And they do it in different ways. The thing has evolved organically. None of the names matched. So the way I use Entity Framework (and I think this is common in a multi-data source kind of world and even single data sources with multiple designers) is that on the Entity Framework side I look at this model and I go, "These are the parts I need. These are all different naming schemes. Let me pick the names that I think are reasonable for my program. Let me throw away the fields I don't want. Let me put in some calculator fields that I do want. Let me change the mapping on the client-side instead of what's on the server-side." So the nice thing about Entity Framework is I'm allowed to do that mapping, and Entity Framework will let me do that while the tables in the database haven't changed. So I'm building my new website with this new view of the same exact data that my live running current website is using.

Franklin: And if I really didn't know who's going into the Entity Framework behind the scenes, my alarm should be going off now saying, " When I select my tables and then I'm writing LINQ Queries against those, are those working at the application level and do I need table access there? Is it writing stored procs for me? What about the SQL that's going back and forth between the Entity Framework and SQL Server? What's that going to look like?”

Sells: In the new version of Entity Framework 4.0 we worked really hard to make sure that that SQL is the SQL that your best SQL admin would write for you. The way LINQ works is: there's this interface, really the core of this language innovative query stuff. It's not the "select" and the "from" and putting things that look like SQL in my C# or VB. It's this interface called IQueryable, and what IQueryable does is when you walk up to something and you get an IQueryable back and you start stacking them up when you say, "Okay, this is a list of stuff from the database and now I want to do a filter based on that. Now I want to do a projection. Now I want to do an order.” Instead of actually pulling all that data, and then filtering it, and ordering it, and projecting it, and doing all of that in memory on the client-side, what it's doing is because it's IQueryable and not IEnumerable, IQueryable is stacking these expressions one on top of each other. When I say go, or I say count, or I say foreach, or I say I want to actually do the data, that's when the LINQ engine is walking that—it's really the LINQ provider that is doing this now. It's walking that list of expressions and coming up with the most appropriate fused round trips to the database that it can do all at once. So it's not just select star. It's select star where, or select whatever you want, where, order by, etc., and if there are other tables that you want to, you can pull them all over at once.

Franklin: I guess what I'm asking then (and this is really a good explanation, thank you) is that your application is going to need access to those tables. It's going to rewrite access to those tables. In other words, the typical way that we would have done it with ADO.NET is we would build stored procedures.

Sells: In Entity Framework, whatever kinds of access you have to those tables, this is the developer, meaning if you've got raw access to the tables, great. Entity Framework can hold them in.

Franklin: It seems that the model works best when you use tables.

Sells: Not true at all. Actually if you’ve just got a set of views or if you've got a mix set of views and tables, that's fine if you've got stored procedures. I mean by default we will generate inserts. I create a new object and I say save changes. We'll generate an insert statement. But if you tell us to in the model, we can go "Oh, never mind. You've got a stored procedure. We'll use that instead." So stored procs, and views, and tables all work great in Entity Framework. So it depends. If you had your database modeled that way, then that's fine.

To listen to or read the full interview go to www.dotnetrocks.com.