Before Entity Framework

When there was no entity framework, developers used to work with ADO.NET. There were different versions of ADO.NET. Before Entity framework there were a few teams that were working in Microsoft Research. One team was working on an ORM for better data access.

First Experience with Entity Framework Team

Julie Lerman is the author of programming Entity framework. According to her:

“I was working with a team even before entity framework came out, even with ADO.NET 1 and ADO.NET 2, I spend a lot of time with them…. So when they introduced Entity framework before it even had a name… I was invited at Microsoft research to meet with a small team, they were working on an ORM so…”

So a team of small people was invited to a meeting by Microsoft Research. This meeting was conducted to show them the new ORM that they were working on. This ORM was built to make data access easier. It was 2006 then, and no one could imagine that it would become a huge success.

What people did before ORM existed

People wrote a lot more code for data access before any ORM existed. They had to write code for maintaining connection to database, and in order to maintain connection through code, one must have sound knowledge of database schema also. If you are calling a store procedure, you have to take care about what’s coming back (return type), what’s going into the procedure (parameters) etc. And further, one has to design domain classes inside the program, manually according to database schema.



Most importantly you’ve to take the data coming from the database and reshape it according to your model inside the application (domain classes), so normally before ORM, developers had to take the data from database and remap it according to the classes objects. It was a lot of work in fact.

And when it came to saving the data back to the database fromthe application it was also a lot of work before the existence of ORMs.

When it’s time to store back up again, persist back to the database, you’ve to take it out of the classes and then create store procedure parameters and push it back up again. So we are writing not only a lot of code for data access from the database but also a lot of code to push back data changes back to the database also. In simple words the CRUD functionality was not so easy [CRUD: create, read, update, delete]. You can say a lot of unnecessary and repeated code has to be written for simple CRUD operations. So Microsoft decided to solve the problem. This was the time when LINQ to SQL and LINQ to Entities came out.

Arrival of “LINQ to SQL” and “Entity Framework”

Developers were facing problems before the existence of any ORM. So it was the time when Microsoft decided to take some action about this.

There were two teams working in Microsoft research that time:
  1. Data access team
  2. C# team
The data access team was working for easy data access and the C# team was working on LINQ at that time to enable string querying on the collections in C# language. So the Entity framework was coming out by the data access team and LINQ to SQL, even though it was data access too, was coming out by the C# team.

Because they were working on LINQ, LINQ to SQL make sense to them. So it was the time when two ORMs met together and made some sense for the Entity framework. When the entity framework team saw LINQ, it obviously made a lot of sense for the EF team to use it for querying because the “LINQ to SQL” team was already using it for querying. [Note: LINQ to SQL is a string based querying ORM]. So they created the implementation of LINQ for entity framework and then we had LINQ to SQL and LINQ to Entities.

  1. LINQ to SQL
  2. LINQ to Entities

LINQ to Entities (Entity Framework):

LINQ to Entities is a part of entity framework that can go to any database.

LINQ to SQL:

LINQ to SQL was specifically written to work with SQL that time.

LINQ to SQL VS Entity Framework

So there were two ORMs at that time. The Microsoft data access team was working on LINQ to SQL andthe Entity framework team, on the other hand, was also performing well. This time there was an environment of competition between both team which was created automatically. Most features that LINQ to SQL was providing were already present in Entity framework. So it didn’t make sense to keep both stacks up.
  1. LINQ to SQL
  2. Entity framework
So, Microsoft didn’t kill LINQ to SQL that time. It’s still evolving but Entity framework was adopted by most of the programmers because of its cool features. But there are many developers who are still using LINQ to SQL for data access ORM. But Microsoft is not investing anymore in LINQ to SQL, instead it is investing in the Entity framework. This is because most of the new frameworks are building upon the entity framework. For example WCF data services etc.

Why choose Entity Framework:

When it comes to choosing an ORM for data access, which should one choose, LINQ to SQL or LINQ to Entities? There is a lot of confusion about it and the answer is straight “entity framework” because it has cool features for developers.

There are different ORMs in the market currently and when someone has to make the decision to choose some ORM, he will first go for the mature version.

Another fantastic feature of Microsoft Entity Framework is that it’s a Microsoft Framework after all, which means if users (developers) want some change in the running version Microsoft will do this them. This is why we can say Entity framework is more responsive to the developer crowd.

Source: Evolution of Entity framework with Julie Lerman.

Read more articles on Entity Framework: