Most-Wanted Features in Entity Framework

by Roopesh Shenoy on Jan 26, 2012 |

The EF team has setup a uservoice forum to let users request and vote for features. We are highlighting the current top 7 most-voted-for feature requests, along with possible workarounds you can use today.

These are the top requested features as of today -

Improved SQL Generation (status=Started)

The request -

I have seen simple select statements with 4 or 5 includes result in nearly 5000 line SQL statements when an equivalent hand-written SQL statement is ~15 lines..

MS has already made some progress on this. Their response -

The update for the core EF libraries that will be included in .NET 4.5 will include some improvements in SQL generation. However not all the scenarios mentioned in the comments will be addressed.

Workaround: No real workaround, except to stop using EF.

Batch CUD support (status=Under Review)

Batching of Creates/Updates/Deletes is a key feature for LOB applications that’s probably missing in most ORMs. Older programming languages like DBase and PowerBuilder had this capability decades ago. Some even suggest that ORMs are not meant for bulk transactions and are most suited for OLTP and not batch processing.

Workarounds –

This extension to EF provides ability to do bulk updates and deletes (but no bulk inserts)
Don’t use Entity Framework for Bulk transactions - write the SQL yourself. In fact this is probably a good place to avoid using the ORM.

EF Support for Second Level Cache (status=Under Review)

This is something supported by NHibernate but not yet by Entity Framework out-of-the-box.

Workaround – Julie Lerman shows how to use Windows Server AppFabric as a second cache in her article “Second-Level Caching in the Entity Framework and AppFabric”

Entity Designer: Speed up & Optimize for using with ~200+ entities

Workaround: Break up the model once it reaches 50-100 entities. This old blog post is still relevant as to why supporting this is not only a technical but also a user-experience challenge. Not sure if MS is going to consider this one, even though it has been voted for.

Support for multiple databases (status=Under Review)

Not supported out-of-box since the model is currently always mapped to a single database.

Workaround – Need to use synonyms, merge two models and trick EF to span multiple databases.

Designer Support GUID as Entity Key – This is more of a bug than a feature where adding the StoreGeneratedPattern attribute on a GUID column using the designer does not update the storage part of the data model. This causes GUID column to get “000..” value while creating new records.

Workaround – Add the StoreGeneratedPattern attribute by hand in the .edmx file as explained here.

Schema Migration a la Rails Migrations (coming in EF 4.3 as Code-First Migrations)

This feature is currently in beta along with EF 4.3. More details about the feature on the msdn blog.

Workaround – Use the database project to create upgrade scripts. Once the Code first drops and recreates a new schema, import it into a new database project, and then deploy it to the old database.

There are many other interesting feature ideas raised by various users, be sure to cast your votes or submit your own ideas and let the EF team know what is important for you!

Related Editorial

Free Book: Graph Databases (by O'Reilly) - Download Now

Impact of Java EE Frameworks on the Structural Quality of Applications

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Betfair Chooses not to Gamble with Database Performance: An AppDyanmics Case Study

Making the Shift from Relational to NoSQL

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Weird ORM tools by M Vleth Posted

Re: Weird ORM tools by Roopesh Shenoy Posted

Re: Weird ORM tools by monser corp Posted

Re: Weird ORM tools by Paulo Pinto Posted

Re: Weird ORM tools by Roopesh Shenoy Posted

Re: Weird ORM tools by Marcel Sorger Posted

EF and SQL teams really need to speak with one voice by Mark Pawelek Posted

Re: EF and SQL teams really need to speak with one voice by Roopesh Shenoy Posted

Bulk CUD by Mickey Bowles Posted

Weird ORM tools by M Vleth

Remarkable that most ORM tools focus on generating SQL, whether it's EF, Hibernate, Datanucleus or whatever. To me that trying to solve a problem that's not there, hence all those tools introduce one. Most developers are perfectly capable of writing understandable, high performance SQL (or whatever language your datastore speaks). The only cumbersome part is that result set mapping to some object model. So please focus on mapping from a relational model to an object model and give the developer control over the SQL, since ORM will never going to get that right.

Re: Weird ORM tools by Roopesh Shenoy

True, but there are advantages to having your business logic entirely in a programming language like C#. For eg, with LINQ to Entities, you could build your query in stages, and have the benefits of better readability and easier debugging at the same time being database agnostic (at least for the databases that the ORM supports). It also reduces the overall code you have to write.

I agree its a tough problem to solve (to make SQL generated by ORM tools equivalent or close to hand-written SQL) but its worth trying.

Another potential solution could be to use micro-ORMs like Dapper or PetaPoco, where as you said, they focus more on object-relational mapping and leave the SQL writing to the developers.

Re: Weird ORM tools by monser corp

Is using C# to build sql really an "advantage"? I really doubt it. Besides showing some shiny fluent API, I really don't see the benefit. As a developer the most important thing I care about is the sql sent to server and the mapped result.

Re: Weird ORM tools by Paulo Pinto

It is more architect friendly. :)

Re: Weird ORM tools by Roopesh Shenoy

EF (I think 4.1 onwards) follows so-called convention-over-configuration approach - so you don't really need to use the fluent API most of the cases. It is convenient, and it does take less code from the developers. Data Access Code routinely forms 25-30% of the code in LOB applications (using hand-coded SQL and manual mapping), and this can be more or less eliminated.

What I meant by LINQ to entities, is that you can form the query in steps (thanks to the IQueryable interface) and it gives you the benefit of being able to debug. Again this is quite convenient.

Similarly loading of associated entities without having to specify joins is another convenience. This makes LINQ queries far more compact than corresponding SQL queries. For eg, imagine the SQL query for the following LINQ-to-entities query, which will contain all the required joins between 5 entities (including the FilmSize entity in the select). More complex the logic, better is the LINQ query to understand and debug -

var consumptions = this.DbContext.ReportRows.Where(p => p.Report.FixedPattern.Customer.FoundryID.Equals(foundryId))
.Select(p => new
{
Date = p.RGReport.ReportDate,
SentToHO = 0,
Consumed = p.FilmSize.Area,
ReceivedFromHO = 0
});

Now this sure doesn't come free, as the no. 1 feature request makes clear.

The question is whether the convenience and smaller code base is worth the trade-off in terms of quality of SQL generated. The answer will depend on the context - and if hand-coded SQL is required, I don't think EF is useful there. Dapper, Massive, PetaPoco are there to fill exactly that need.

EF and SQL teams really need to speak with one voice by Mark Pawelek

In the forum mentioned above, the 3rd most requested feature is: "EF Support for Second Level Cache". Wanting this is a mistake. What's really needed is a non-relational database to separate the data into two views. A core (CRUD, relational view) and the query view, e.g. working a little bit like RavenDB. The kind of database I'm talking about would be designed to overcome the ACID requirement of data consistency: every CRUD change would seamlessly trigger an update to the query view. Imagine this query view being a set of indices; one for each query, but far faster than SQL Server's index rebuilding features and happening behind the scenes constantly as database inserts, deletes and updates are done.

The big problem here is that each team are atomised. The EF team do EF stuff, the database team do SQL Server stuff. You need one team to do both.

Re: EF and SQL teams really need to speak with one voice by Roopesh Shenoy

Thanks Mark; I can see how the pattern you are mentioning would be useful for scaling and improving read performance; I guess the advantage is that the query view is loaded in advance, before first query call is made to the database. The only potential bottlenecks I see is how fast the query view gets updated (the faster the db we pick, the more compromise we may have to make on the consistency of the cache) and the extra load added on the database by the triggers themselves.

However this would still be useful where people don't mind a little delay, and we could batch the updates to the query view every few minutes. I think the folks at StackExchange use a similar approach.

Are you aware of any tools that allow something similar today, without having to do everything manually?

Meanwhile note that these are feature requests voted by users which affect the ranking, nothing that the EF team has directly contributed to. If you just throw a note in there about this alternative, it might provide food for thought to Microsoft.

Re: Weird ORM tools by Marcel Sorger

The problem is that most developers think they can write high performance SQL, but most DBA's think otherwise.
Having a DBA makes makes a lot of difference as DB performance and correctness is what those people do. If there is no DBA those dimensions may not be very important. Consequently you might be wasting time and money on optimizing SQL, while you could have used an higher level tool and create more features.

Bulk CUD by Mickey Bowles

Interesting that it is suggested to go straight to SQL for this. When doing code-first with EF, you are green fielding. In the past week I have had 3 new projects cross my desk with the solution being EF code-first. Two of them have bulk CUD needs. Really defeats the purpose...