Any technology choice should be properly investigated (at least a representative spike should be done) before actually using it in a real project. If you had done the research in advance, you probably wouldn’t have gone with Linq To Sql since it’s very clear that it is limited to SQL Server only. Entity Framework is supposed to be database independent, but it’s always been very clear that providers for other databases aren’t necessarily available and nobody ever said they would be free.

As for NHibernate, there are indeed many choices, most of which should be made based on the outcome of your spike or your research.

I don’t think the current problem you’re facing can be blamed on any ORM… i think it’s because your team did not do the proper research in advance. If your team was not given the proper time to do this research, then it’s a management problem that no piece of technology will ever be able to fix.

ORM idealists have been stating for a long time that ORM’s are portable and easy to use. I have read place after place that NHibernate is just as good if not better than LINQ and I have heard the same arguments for the opposite. I have followed down the ORM path only to be disappointed by these promises. You might use the argument like you did in your article that my knowledge in the tool isn’t good enough or that I’m not using it right. However, as I’ll described below, I don’t think there’s enough time to gain the expertise needed with some of these ORM’s when there are actual deadlines.

The current project that I am currently working on has taken far too many months to implement because I’m trying to use ORMs. Prior to this project I learned LINQ which was very easy to learn and quite enjoyable; however, now I need to connect to an ISeries DB2 server. LINQ does not have support for DB2 which breaks one of the promises with portability. Microsoft developed the Entity Modeling framework to achieve this but after much research, I find that it will only work when the database vendor creates connectivity for Microsoft’s Entity Modeling framework. After further research I find that IBM has developed such connectivity but it costs $11,000. There’s very little information about IBM’s framework, no demos that I can find, so I don’t know if it would be worth the money.

I then find NHibernate and become hopeful. It is touted as a competitor to LINQ, it fully impliments ORM, yadda, yadda. However, as you admitted in one of your posts, the documentation is simplistic and lackluster which for me has been one of the most frustrating things about the product. When beginning with NHibernate a person has a lot of decisions to make. Do you want source code or not. If you do you have to then download SVN and Nant. If you don’t proceed. Then, you have to decide whether you want to map using XML, NHibernate.Mapping.Attributes, or fluent. This involves more research and hopefully you’ve made the right decision.

Now, you have to decide on a proxy. There appears to be five available. Again, more research and again, hopefully the right one is chosen. So I went down the path of no source code (I now regret that but have since downloaded), Using NHibernate.Mapping.Attributes (I now regret), and using Castle (No regrets, lucky decision). I also attempted to utilize Rhino commons by downloading the source but that in itself left much frustration as I couldn’t get it to compile with Nant and when I submitted questions to the user groups I received no answers. Finding lack of support about NHibernate tools and NHibernate itself is common.

In my scenario, I’m working with tables that have composite keys (not my choice). I could get the composite key mappings to work but not the associations. Finding clear and useful examples of one-to-many relationships using composite keys is next to impossible. I have now decided to give up on NHibernate because I foresee myself facing even more problems and am going back to a more simplistic and possible approach: ADO.Net.

In the end, business managers don’t care about ORMs or a person’s troubles with them, they just want the finished product.

You’re correct in stating that there are several techniques for addressing the issues I detailed in my post. We utilized the techniques that you suggested as well as several additional techniques. Again, my issue is not a lack of means to address performance issues but that the means often require deeper knowledge of the ORM than is commonly acknowledged.

BTW, HQL was never really an issue with our team, since most people with SQL skills seem to become fluent in HQL within a few days.

@Davy, @Craig

The problem we had with using something other than the ORM to do reporting was that the objects in our model contained logic & behavior that we wanted to leverage on our reports. Not using the ORM meant that we’d be either duplicating behavior or duplicating data access code, neither of which was an ideal solution.

@All

I’d like to echo what Den Ben wrote. The information that is available on the Internet is out there because smart, passionate developers like you care enough to write & comment about the subjects.

To return to my original point, I’ve used and will continue to use ORM solutions, but not every issue that developers have with them is caused by lazy and/or ignorant developers. There are definitely use cases in which developers will need to dig deep into the architecture of the tool in order to extract good performance.

yes definitely… ORM is great for a lot of applications, but definitely not all of them

and parts like reporting should never work with an ORM IMO

I agree with your assessment. I also agree with Davy. However, what remains to be said is simply that not every tool fits every situation. You mention reporting. I quite frankly do not even attempt any level of complex reporting using an ORM. There are many reporting tools out there for that. ORM wasn’t meant to solve the reporting problem, so lets not even try to push it into that bucket.

If you need to optimize the efficiency of an specific query using a well optimized SQL string or SP instead of an HQL or criteria you have a seamless way to do it even without changing the code only the mapping between and so an optimized sql query and ORM keep being compatible, and there isn’t a point there.

I sometimes even don’t know how to write something in HQL, i write it in SQL and when i learn how to do it the HQL way if i benefit from this i replace the mapping if not i live it as is.

Gustavo.

Well put!

Luckily it’s the effort that some people invest in ORM technologies (like Davy does with NHibernate) and that they want to share with the developer community (again.. Davy does a nice job at that) which allows us to get acquainted a bit deeper than on just the “friends” level. I plan on making 2nd base in the near future

I feel like I have a decent grasp of both databases/SQL and ORMs (or Hibernate, at least), having written tens of thousands of lines of stored procedure code as well as having used Hibernate to develop a 100+ KLOC production system. The ORM design/usage was reviewed and validated by Hibernate consultants working for Red Hat /JBoss.

IMHO, there exist situations which are fairly trivial to handle from a SQL perspective that, in order to get acceptable performance, require using ORM techniques that are often sparsely documented. Reporting often falls into this category, as do operations in which large numbers of objects/records must be matched and/or reconciled. The performance issues typically do not become apparent until a system has hundreds of thousands or millions of rows in key transactional tables.

Of course, systems using straight SQL are not immune to this effect, but there are literally hundreds of books and thousands of articles about tuning SQL queries, while the techniques for obtaining the best results with an ORM are harder to find and, for me at least, involved significant research and trial & error.

In summary, an ORM can definitely be your friend when it comes to reducing the amount of time you need to spend writing data access code, but once you’ve accumulated enough data, you might have to become more than just “friends” with your ORM and become intimate with her inner workings.