On a recent enterprise ASP.NET MVC client project, I was introduced to using Microsoft’s Entity Framework for the first time. I was skeptical at first, thinking that an abstraction layer with LINQ over the database would slow things down performance-wise from the standard .NET calls to SQL procedures (there is a performance cost to using LINQ). I have written and modified thousands of stored procedures, which work reliably well, but don’t have the same development, design, and maintenance advantages with LINQ, Entity SQL, and so forth. Alternatively, using stored procedures requires a thorough understanding of SQL and the “impedance mismatch” between .NET object/procedural code and the set-based operations of a SQL engine.
I was blown away by the speed of the Entity Framework – honestly. I’d never seen database transactions happen that fast when stored procedures were not part of the solution, and with Entity Framework, there is no need for a library of stored procedures. Now part of it could have been the latest and greatest virtual SQL Server 2016 instances in use.
Setting that aside for a moment, I don’t know how one could go wrong with Entity Framework as a starting point for getting away from the standard repertoire (or jungle) of hundreds or even thousands of stored procedures, views, user-defined scalar and table-valued functions, all called from (usually) hand-coded DAL abstraction layers or form-classes in ASP.NET, WinForms, etc. It’s typically quite a bit to manage on it’s own, and change-analysis on a database server is usually a very time-consuming and tedious undertaking, with or without the benefit of script source-control. Entity Framework makes data-persistence much more manageable for everyone.
Industry was slow to adopt the Entity Framework due to performance bugs in the first versions. As as a result, Microsoft was forced to update it quickly, moving from v1 to v4 in fairly short order. By the time the framework had evolved to version 4, industry adoption rates picked up pace and a few performance kinks were worked out. As of early 2017, version 6 has been out for a while, and adoption is even better, for those enterprises that understand the benefit of adoption, and have the time and resources to implement it.
- One queries strongly-typed domain entities like: Customer, Order, LineItem, TimePeriod, etc.
- It completely replaces a typical DAL layer.
- If any, the learning curve of using the many flavors of LINQ.
I have a very high regard for the Entity Framework 4 and higher (current iteration is 6) and look forward to using it in any client project where I can.