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.
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):
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.
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.
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.
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#