Evolution of the Entity Framework: Lesson 2

Tuesday, June 19, 2012

The first version of the Entity Framework appeared in the second half of 2008 with an API derived from WinFS and a heavy theoretical focus on entity-relationship modeling. While other object relational mapping frameworks viewed mapping as a (sometimes) necessary evil, entity mapping was a centerpiece of the Entity Framework.

The Entity Framework vision was to create a conceptual data model representing entities and their relationships. The conceptual model would be the ideal model for application developers. You didn’t have to think about database tables or normalization when building the conceptual model. Instead, you were supposed to focus on the important business objects and concepts. Once the model was in place, the Entity Framework could use the model to generate code for programming against the conceptual model inside an application, as well as generate database structures to persist data represented in the model into a relational database. The theory and math behind was the mapping was spelled out in an impressive piece of academic work titled “Compiling Mappings to Bridge Applications and Databases”.

But the Entity Framework vision went beyond just traditional application development and relational databases. It was thought that the conceptual entity data model could be the canonical data model for an entire enterprise, and drive not only line of business applications but also reporting, synchronization services, web services, and data analysis.

Entity Framework Vision

Unfortunately, the Entity Framework, like its predecessor, set out to solve a broad set of problems in enterprise IT and missed the opportunity to solve a specific, common problem in a way that would make developers happy. By the time the framework officially shipped with a Visual Studio service pack, the developer community had already highlighted a number of shortcomings for accessing a relational database from the Entity Framework, which included (but was not limited to):

  • · Unimplemented LINQ operators
  • · No capability for model-first design
  • · No support for complex types
  • · No support for enum types or unsigned integers
  • · No implicit loading of relationships
  • · Limited stored procedure support
  • · Unnecessarily complexity in generated SQL code
  • · Unnecessary complexity and dependencies in generated C# code
  • · Performance

Since developers love to benchmark software, it was the last bullet, performance, that generated many blog posts comparing the Entity Framework to other object relational mapping frameworks like nHibernate and LINQ to SQL. LINQ to SQL ironically was never intended to see the light of day but did ship earlier than the Entity Framework and was gaining in popularity because it was simple to understand and solved the ORM problem in a straightforward fashion. Because LINQ to SQL has fewer architectural layers, it outperformed the Entity Framework in almost every scenario.

Entity Framework Benchmarks

Developers looked to the Entity Framework to solve one specific problem, but the framework lagged other frameworks in almost every area. When you look around at successful products, you’ll typically find they solve at least one problem extremely well. Dropbox, for example, has a minimalistic feature set compared to other file synchronization applications. But, Dropbox is hugely successful because Dropbox does file synchronization extremely well. In fact, the success of Dropbox was the topic for a question on Quora.

Well, let's take a step back and think about the sync problem and what the ideal solution for it would do:

· There would be a folder.

· You'd put your stuff in it.

· It would sync.

They built that.

Why didn't anyone else build that? I have no idea.

"But," you may ask, "so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!"

No, shut up. People don't use that crap. They just want a folder. A folder that syncs.

Lesson 2: Solve At Least One Customer Problem Well

Early frustrations around the Entity Framework primarily arose because the framework didn’t solve a specific problem well. In turn, this led to negative reviews.

As the pressure mounted on the Entity Framework, another learning opportunity arose which we’ll look at in a future post.


Comments
gravatar Mark Tuesday, June 19, 2012
tx interesting read
gravatar John Tuesday, June 19, 2012
I was interested by the first part of your EF series so I watched your talk (Scott Allen - Evolution of the Entity Framework) from NDC 2012.

It's available at: http://vimeo.com/43676913
James Tuesday, June 19, 2012
@John - Spoiler Alert! :)
gravatar tobi Tuesday, June 19, 2012
This is so true.

One thing that it does better than others though is the designer surface. I have always missed that with NHibernate.

Ok, now back to trampling EF down into the dust.
gravatar Scott Allen Wednesday, June 20, 2012
@John - yeah, wasn't real happy with my performance, but, there it is on the Internet.
gravatar Mike Friday, June 22, 2012
I take it you will also write about the open letter to Microsoft from the (Alt.net) community? That was some cool soap opera...
scott Friday, June 22, 2012
@mike - yes
gravatar bob Friday, June 22, 2012
Hi Scott, I just checked that talk that you're not happy with, and I wish to encourage you to keep doing those talks, because I liked it.
gravatar Alf Kåre Lefdal Friday, June 22, 2012
I agree with @bob. I was at your talk at NDC2012, and it is marvelous how you can make a seemingly boring topic like Entity Framework into such a great presentation of development practices. Keep up the good work.
gravatar scott Saturday, June 23, 2012
Thanks, guys.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!