I had a brief IM discussion today with Adam Cogan. Adam doesn't know me but I've known him since back in ... hmm ... 2001(?) when I attended a presentation he did on Reporting Services for SQL Server 2000 in Canberra. Since then I've seen him present a few times (both in person and on DNRTV) and I've even had the honour of being quoted on his company's web site.

So we were chatting (among other things) about the ADO.NET Entity Framework, about which Adam ran a presentation at this year's Code Camp Oz. Unfortunately we had to be back in Albury by 6:30 so we didn't get to see all of the presentation, but I made it pretty clear on my Twitter feed that I was yet to be convinced about the EF.

Adam asked whether I use an ORM right now, and I had to admit that right now we're on something of a cusp at work. We're just now starting to abandon typed DataSets and use our own class hierarchy to model our business domain objects. However, we haven't yet started using any kind of ORM. We're rolling our own using plain old ADO.NET.

Why would we be wasting time coding old-fashioned ADO.NET rather than using a proper ORM? I don't have any good answer to that, but I'll put some thoughts down here and see if I can come to some sort of conclusion.

When I first started doing Windows development at work, we were using version 1.0 of Borland Delphi. Delphi was an awesome product with a rich component framework, but every once in a while there was something that was easier to do if you called down to the Win32 API. Not only that, having a knowledge of what Delphi was doing "under the hood" (in terms of window handles etc) came as a real advantage.

I guess that attitude has kind of stuck with me over the years, and any time I see a new technology come along, I'm interested in starting (as much as possible) with "first principles" and doing things "the long way" before jumping in. So I guess subconsciously I've decided to try rolling my own ORM before jumping head-first into a third party one.

Another reason I haven't leapt straight into using an ORM is that right now at work we're introducing a lot of new things. Not only the idea of using an object model instead of DataSets, but also some more fundamental changes like unit testing and mocking. As much as possible I want to limit the amount of "new" that I introduce at once - not just for everyone else's benefit but for my own too.

Where to from here then? I think we'll roll out a project or two using hand-written ADO.NET code until we have a good grasp of what we're doing, and then start investigating our options: The likes of NHibernate, SubSonic, LLBLGen, and the Microsoft offerings like LINQ to SQL and the Entity Framework.

In the meantime I'll keep my eyes (and mind) open!