Entity Framework by many regards has been a cluster since it’s inception. Entity Framework came out approximately in January of 2008. They say software often mirrors the organization building it and I think that “ism” holds true in this case. When EF came out, there was an already loved ORM, Linq to SQL, out and in use. Microsoft decided to build a new ORM from scratch instead of enhancing Linq to SQL… classic Microsoft. This decision reflects Microsoft has lots of groups that develop overlapping functionality with different agendas. Linq to SQL has been more feature rich than EF for almost 4 years despite having much lower resource allocation. At the end of the day, is the Linq to SQL base code better than EFs?
Just to illustrate one major frustration with EF is that it hasn’t supported enums. It has been missing true enum support since all of 2008, 2009, 2010, 2011, and part of 2012. It has taken over 4 years to add enum support to EF. Another frustrating point has been that EF has been a performance dog compared to raw ADO .NET and even it’s Microsoft cousin, Linq to Sql.
EF, almost 5+ years later it matches the feature set of Linq to SQL and almost 7+ years matches the feature set of Rails ActiveRecord. WTF? Microsoft should revel in the fact that many shops will only use Microsoft solutions and give us at least competive tooling. EF of yester year has harmed many .NET shops that are exclusive to MS solutions. In the Rails community you aren't condemned for using ActiveRecord. In the .NET community you have to question the usage of EF for your product heavily. Microsoft, long ago, should of continued improving EF to the point where using it wasn't considered a liability by many .NET practitioners. I’ll go on record saying that I really like the new EF Code First and dbContext paradigm. I have found it easy to use and understand and it makes getting a site up and running, from a data access perspective, almost trivial.
Packaging EF with the .NET core has proved to be a major stumbling block for enhancing EF over the years. Experience has shown that frequent incremental releases is what makes a great product. By pushing the latest versions of EF to separate dlls that are updated frequently has greatly enhanced the EF product. In the past year we have gotten DbContext, Database Migrations, and Fluent Code Mappings.
The next version of EF will have major performance improvements but we shouldn't have to wait for EF 6 to have the next set of performance changes. If Microsoft wants to do EF right though they need to do the following…
EF should be fully pushed outside of the .NET framework and open sourced.
EF should post performance numbers, ala Dapper, that come within 10-30% for most queries when compared to common frameworks. Simple select statements that materialize to a single object or list of objects should be blazing fast.