Should an O/R mapper be a code generator? My thoughts...

I saw this question raised on Steve Eichart's blog, and some strong and well formed opinions about it all.

I recall reading this discussion and thinking "I really don't care if an O/R mapper is a code generator or not. As long as the vendor communicates how their tool works so I can assess if it's suitable for my needs."

Writing our own data access plumbing code is hard work, so it makes sense to find a tool that eases the pain. There's loads of tools for this job, and the whole "data access problem" can be solved in many ways.

Selecting tools is a timely process, and vendors should (and do) go to great lengths to help us determine if their tool will support our project well.

I personally don't really think that there is a right and wrong approach to data access. You just have to pick a tool that works for you, and that fits nicely with your project. I've only used a few tools so far, but I'm going to keep trying new ones because I learn so much from taking different appraoches.

I love NHibernate for it's flexibility. However, because NHIbernate has so many options, getting off the ground can take time.

NHibernate is certainly well suited to legacy projects where I'm not in a position to change the database tables, and the more tricky situations where you might have things like composite keys, different identity schemes, and value type mappings. It can take time (and therefore money) to to learn to use these features, but if you're project needs such flexibility then it's there for you. NHibernate was built to solve certain kind of problems very well.

I'll other projects I'll be considering LLBLGEN pro. I've heard great reviews, and I think there's some very valid reasoning in the approach the tool takes. Sometimes I find myself fighting NHibernate - so perhaps LLBLGen is going ease the pain more than NHibernate can in some projects. Not on all projects, just some.

I've also been using Ruby on Rails with it's Active Record library. This is fantastic - it's so darn simple. For some projects it offers more than enough, and allows for seriously fast development speeds. However, it's limited because it relies heavily on convention. Who cares?

I used to think that I wanted tools that provide the ultimate in flexibility and features. Now my mind is changed. I just want tools that makes easy work of the problem in hand.

If solving the problem well means that generating code is more appropraite than reflecting on types at runtime, then that's fine. Or, if it means sacrificing mapping flexibility, having to follow strict conventions, but in exchange for great development time savings, then that's great too. Finally, if it means having to read and understand lots of docmentation, but having the ability to implement very complex mappings, then that's fine too if that's what the projects needs.

In my humble opinion, it's all down to what the project will benefit from most.