ORM (object relation mapping) libraries have been around since a long time. Ever since my first job, converting relational data to classes and back has been part of everyday life. It was the world of ADO and record-sets were everything. Mostly folks would pass around record-sets as data transfer object directly. A few projects used record-sets while performing data-access and converted the rows to objects manually.
2003 was the first time I used a 'proper' ORM library - nHibernate. It worked pretty well for my own hobby projects but I have never seen any ORM library being used in any enterprise product I have worked on. Fast forward to 2014, Entity Framework and MVC are everywhere; a perfect match. Getting basic entities working together isn't too tough but dig a little deeper, I see quite a mess in the number of ways a single task can be completed. I know I am right because of the number of questions posted on various sites like Stack Exchange, MSDN and other about things like 'what's the difference between ObjectContext and DbContext'. These classes are part of the framework and such questions shouldn't even arise yet I too have searched for answers for exactly such basic concepts. The reason is lack of good documentation. It seems the EF project is trying to address every possible scenario and leaving each incomplete.
It seems the EF effort is changing rapidly and yet not providing support for basic features like calling user defined functions and stored procedures in a code-first scenario. Having said that, Entity Framework is the quickest way to get a smallish project up and running and its fits so perfectly with the ASP.NET MVC way of developing web sites and even WPF.