I'm currently working on a mini-project with Microsoft (more news on this next year) - and the project team are keen for this project to be exemplar of recommended MS technologies. So (where appropriate), the system makes use of Entity Framework (EF) and ADO.NET Data Services - two technologies that I know a bit about, but have only previously toyed with (although I've done a lot with their cousins, LINQ-to-SQL and WCF).
Now, I've commented a few times in the past about the short-comings of EF, but this project has been a good opportunity to do something non-trivial start-to-end with it. And while I'm still not an EF evangelist, I'm now not quite so hostile towards it.
The truth is: if I hadn't seen LINQ-to-SQL, I'd probably be delighted with EF as a LINQ back-end. Forgetting about architectural purity concerns (POCO, etc), there are still a number of annoying glitches with EF, including:
LOLA - things that work with most other IQueryable<T> implementations, but not EF:
- No support for Single()
- No support for expression-composition (Expression.Invoke)
- Skip()/Take() demand an ordered sequence (IOrderedQueryable<T>)
General annoyances:
- Limited support for composable UDF usage
- A few niggles with the detach mechanism
- Some lazy loading issues
- Lack of "delete all" - a pain for reset scripts, but probably not very helpful in production code ;-p
On the plus side, the ability to remove trivial many-to-many link tables from the conceptual model makes the programming experience much nicer - but this is the only thing I've used in EF that I couldn't have done just as easily with LINQ-to-SQL.
But: it gets the job done. If anything, the exercise has gone a long way to making me feel warm and cosy about the future of EF: if the team can take the flexibility of the EF model, but squeeze in the bits that LINQ-to-SQL gets so right, I'll be a happy coder.
(In my next post, I hope to discuss my experiences with ADO.NET Data Services)
