Thoughts on ORM

I’ve posted before about issues I’m having either with behaviors of nHibernate, or behaviors of teams using nHibernate, but I don’t think I’ve made my thoughts on ORM too clear. Let me do that now.

I think some form of ORM is here to stay. There are lots of different ORM tools out there and acceptance of them is absolutely growing. Further, it should grow. Developing software is hard and if you can write code that reduces the overall amount of code you have to write, I’m in favor of it. I’m not convinced that the current crop of tools are quite as good as they ought to be, but most of them seem very flexible which should mean implementation of them can be, overall, beneficial to your project.

That’s all to the good. The problem is, and I don’t know if this is intentional marketing, poor understanding or just a general lack of ability, these tools are being hyped, or are perceived to be hyped, as a way to completely ignore and hide the unfortunate fact that there’s this dirty, tainted, completely un-object-oriented relational data engine persisting our information (or storing our data, if you will). Somehow, the idea that with an ORM tool, you can, and should, completely ignore the very idea of the database is persistant. Don’t believe me? Read through this excellent post by Daniel Auger. This guy is not in the enemy camp when it comes to ORM tools. He’s the very epitome of a booster of ORM. But read that post. Understand what it says. You need to take into account that you have a database, not a persistance layer, that is storing data, not information, into a relational data engine, not an object model. If you don’t, your ORM project will fail.

That’s all I’m after. I’m not advocating for the elimination of ORM tools. I think that’s silly. I see their benefit (conceptually, in my own experience to date, I haven’t seen any actual benefit at all). I’m in favor of them. Let me say that again, just so we’re clear, I am in favor of implementing ORM tools. But, I think if you’re implementing an ORM tool and there’s not a database developer or DBA involved with your project… you’re looking at trouble. Remember what ORM stands for, Object Relational Mapping. Relational is still a piece of the puzzle. Pretending otherwise doesn’t make the problem go away, it exacerbates it.

As an aside for those who are still reading, I wrote this whole thing after being inspired by reading Mr. Auger’s great post. That’s a developer I’d love to work with and learn from.

2 thoughts on “Thoughts on ORM

  • ” But, I think if you’re implementing an ORM tool and there’s not a database developer or DBA involved with your project… you’re looking at trouble. ”

    I agree with this. We use an agile process and the DBA’s are actively involved as are the QA and product teams. ORMs, NHibernate, in our case, definitely simplifies the coding process.

    ORMs (and sql for that matter) are complicated and education should be a priority so it is used effectively. NHibernate in Action as mentioned in one of the comments is a must read – I’ve read many chapters multiple times. The wiki’s and on-line groups are great too as well as the numerous webcasts and blogs. The high quantity of these indicates that there is a lot of learning to be done and the community does not think it is a magic bullet.

  • scarydba

    Hi,

    Thanks for stopping by again and leaving another great comment. I do agree with you. It’s very clear that there’s a healthy and active ORM and nHibernate community that recognizes the strengths & weaknesses of their tool. Same with the SQL Server community. Unfortunately, I don’t think either community represents the majority of the users of both technologies and I don’t think either community cross-communicates nearly enough (except occasionally like this). Like I said above, I recognize the utility of ORM. I just wish I could say I’ve seen the utility in action.

Please let me know what you think about this article or any questions:

This site uses Akismet to reduce spam. Learn how your comment data is processed.