If any of you have been affected by the bug I mentioned in my last post, there's good news - the EF dev team have fixed it and it the update will appear in the next update of the framework!

Take a look at the connect item here, and you see that, despite my not being able to reproduce the bug reliably in a standalone project (I spent a good few hours trying to as well!) they obviously could see that there was a problem and went ahead and did it anyway.

Now that's what I call service.

Okay - so I know a lot of cynical developers out there would say that such problems shouldn't appear in so-called battle-ready frameworks released at such a core level, but the reality of software development is that you do get bugs.  Open-source software is riddled with them, and the only reason most people don't get the arse about that is because there's a perceived difference in the aims of the developers in question - Open-source developers do it for the community, while Microsoft et al do it for the money.

Well, I'm afraid to burst the bubble, but show me an open source project out there that couldn't be bought out, at any price, for the mutual benefit of the originating developers and I'll show you a jellyfish that can play football.  Okay, I'll yield to Linux - but then that's had a ridiculously long gestation period and, in any case, I'm talking more about developer productivity components here.

So, yeah, Microsoft do gain a commercial advantage by encouraging people to use technologies that naturally partner up with stuff that has a license fee (Linq To SQL and SQL Server; or EF and SQL Server; WCF and Biztalk), but the fact is that you can either choose to opt into that or not.  It's like democracy - if you choose to opt out of it, then your views are, unfortunately, worth a great deal less than those of people that didn't.

Apologies to EF

As I hinted in my last post, my views are changing on EF - and, no, it's not because those nice folks over there fixed a bug of mine.  Here's a few reasons, in no particular order:

nHibernate isn't all that. 

In our tests of ORM frameworks, including L2S, EF and nHibernate (yeah there's more, but you have to limit the list a bit!), we expected nHibernate to perform the best, have the best interface, and generally out-shine the other two.

It's reputation preceded it - having read so many things about it.  We had this expectation, because of it's pedigree and the fact that it's had a decent group of people and a huge community behind it for quite a long time, that all performance issues would have been sorted and that the documentation would be top-notch. 

It has to be said, we were left extremely disappointed.  In terms of basic setup, it is impressive.  It's XML configuration is indeed lighter than both of the other two - but since the other two have designer support (which will only improve over time) you don't have to do much writing at all - but if you do need to, you can.

The caching of objects threw us out - on more than one occasion we had to forcibly invalidate the cache after performing an update in order to be able to re-select an object from the database with the expected state.  When using L2S and EF this is never an issue - some caching is done under the hood, but never has it got in the way of getting stuff working - and if we want more caching, we can plug it on top.

But the biggest problem was performance.  Now, if any nHibernate die-hards read this blog entry and feel so-inclined, I'm sure I will be told that we must be using it wrong.  Sorry, but we went through about 3 or 4 different patterns for using the the nHibernate session (my colleague read a big post by somebody else in the community about nHib best-practises etc and followed that), and no matter what we did our nHib tests always ran 5 times slower than our L2S and EF ones.  It was the same test script calling abstract methods on the same base type, with the differing implementations sitting behind them.

I can't help thinking, then, that the reason for so much faith being placed in nHibernate is because of it's provenance - the feeling that it's been made by 'good guys' for 'good guys' - and that the negativity surrounding EF is because it's made by Microsoft.

The future's bright

I've been playing around quite a bit recently with WCF services - I have to say that this particular technology does rock - and even more recently I've been looking at RESTful services in WCF.  If you're interested in learning more, then I strongly suggest taking a look at this article on MSDN written by Aaron Skonnard - explains some of the basics behind RESTful services and walks you through setting them up in WCF.  Look out for an update soon when my company (well, the one that I work for) will start releasing a whole bunch of systems built around these - geared around helping you find your next job.

One particularly interesting feature that I've yet to play with is that of ADO.Net Data Services.  In the example Aaron looks at, he takes an Entity Data Model (EDM) and, with the minimum of effort, exposes the entire model as a set of RESTful resources, with query support.

This is all made possible by the tight integration of Linq and IQueryable<T> into the entity framework - and in the future we can expect to see the ability to port around change-tracking on objects that are produced from a service-based endpoint and then submitted back to that endpoint for saving.  In this scenario, the same client code could be bound either directly to the entity data model built on top of the database, or to one which is bound to a set of RESTful services, and with the possibility of including this functionality into Silverlight in the future (currently it's bound specifically to a SOAP interface, but that will change), I have to say Microsoft's aim of providing so-called cloud-based frameworks is looking a good bet for the rest of us.

Despite all this, I'm still not using EF in production code - unlike L2S, which has seen an outing.  The next time I write an internal monitoring/reporting app I might look at using it so I can get a bit cosier with it; but one thing's for sure I'm going to be awaiting the next update with much eagerness - as I really feel it's got legs and is something that many of us (including you nHib die-hards!) will end up using eventually.