Most-Wanted Features in Entity Framework
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.
- 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!
Weird ORM tools
Re: Weird ORM tools
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
Re: Weird ORM tools
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
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
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
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.