Ted Neward has an article at MSDN about Linq (Microsoft next generation data accress layer / ORM) and the rest of the tools that are out there in the field for data acess. I agree with most of the article, and I was excited as any when I first saw Linq (can you imagine walking to a client and telling him that this is The Microsoft way to do so, instead of having them insist on datasets?).

The problem that I have is that it make some broad generalizations about the rest of the tools, more spesficailly, on N/Hibernate. To be spesific, this quote:

There are so many things that I've a problem here that I've a hard time to know where to start.

• "... attempts to hide data retrieval strategies behind object interfaces ..." - Yes, and? That is the whole point of an ORM, I don't want  to know about the data retrieval strategy. I do want to be able to say "give me Ayende's Blog and all the posts from december" without caring how this is done.
• "... attempts to model relationships between tables in the data store with relationships between objects ..." - I call bull on this one. I wrote a highly complex business model that had very little to do with the underlying database structure. I was neither constrained nor force to change my model for the database, or the other way around.
• "... an inability to address strongly typed "partial object" queries ..." - I'm not sure what he is talking about here, but in my project, there is one place where I used strings to expressed a query, and that was because what I needed could not be expressed without the type semantics of the CLR.

The only thing that Linq has is that they same guys that write the programming languages are writing it. I can guarantee that NHibernate will take advantage of those features before long, and there are similar implementation to Linq right now, in db4o products. The rest of the problems he specified which was the select N + 1 and loading large amounts of data can be solved by any ORM that I know of, and they will be a problem for Linq as well.

I used to be a pretty heavy C++ guy, I loved reading and writing template heavy code, playing with pointers, playing as close to the hardware as it is possible in modern OS. Then I met the CLR, and I realize that I could be far more productive if I didn't have to think about memory handling all the time. That is not to say that I can afford not to think about it, it just mean that I don't need to be aware of the implications of each and every line of code (anyone can recall the lessons about what can cause exceptions and what can't?). Beyond an integer assignment, I think that anything could, and you needed to be aware of that and be sure to release memory. That is without talking about buffer overflows or segmentation fault.

I feel the same way about ORM. I know SQL, I think that it is a great language to do all sort of cool stuff (most of which I'm currently finding out about), but I don't think that it has a place in a business application. ORM frees you to work on a business concerns, no on the details of my data access strategy. Like in the GC, you can't really ignore it, but it gets the data out of your way. When you need to optimize, it's very easy to do so. I managed to take a page from 91 queries per page view to just 3 (and I don't think that I could have gone down to less than 2 if I tried hard) in a few hours.