More and more interest for O/R Mappers

Thanks to ObjectSpaces there is more and more interest in O/R Mappers in the Microsoft community. I know that several of the vendors of O/R Mappers for .NET are worried (of course) since Microsoft will ship ObjectSpaces as part of the .NET Framework. But perhaps ObjectSpaces might be a good thing for those vendors because it will help attract a lot of developer interest to this area.

I also think that several people (count me in) wanted to see something like JDO (Java Data Objects) for .NET, namely a spec that several companies could implement. Microsoft's tradition is different, as you know, as they go for an implementation instead. Yet perhaps there will be syntax compatible ObjectSpaces clones, using the Microsoft implementation as a spec. Could there be clones that, for example, support databases other than SQL Server if ObjectSpaces won't? (Disclaimer: I don't know for sure if this is allowed, but companies building products will of course know the ins and outs.)

BTW, absolutely one of the best books of last year was, in my opinion, Java Data Objects by David Jordan and Craig Russell. It's very interesting as a design book, even if you don't plan to use JDO by itself. The book is full of interesting solutions to design problems and it comes highly recommended!

Ingo Rammer wrote about weaknesses in the concept of O/R Mappers here. Not that Ingo is wrong, of course and you should use the right tool for the job. However, I felt I needed to comment on the second part where he talks about the transactional update. My comment was going to be something along the lines of how I solve that particular update problem by using optimistic locking (if possible, but it's almost never a good idea in this particular context of an inventory table) or by jumping out outside of the O/R Mapper, to custom SQL code or a sproc. (If you design for it, jumping "out" can be done pretty transparently of course.) But this problem got me thinking about one area of how the O/R Mapper concept could be extended. See more about that in this post.

It's weird, but for the last fifteen years I've to a large degree earned my living using SQL. Now I find myself defending solutions for where hand-written SQL could be avoided. Except when REALLY needed of course.