I believe we have done a discussion post on IoC and Repositories. For IoC it sounded like we were all in agreement that once you get into the pattern it's hard to not use it, the complexity fades away, and the extra upkeep saves you code in other ways. For Repositories I believe hit on trying to properly use the term and trying to restrict their abilities. Now I'm thinking we should do a post to discuss the use of Object-Relational Mappers or ORMs.
I personally am finding the use of an ORM almost always worth it. Your code takes a completely different shape and a lot of worries you had to deal with yourself almost vanish and are replaced with much easier to maintain ORM configuration code. That is once you learn the ORM.
The majority of my experience is with NHibernate and I am still learning this beast, but it has some extreme power at your figure tips. You sometimes almost feel like an evil conjurer summoning the magic of powerful dark wizards (this is natural because you are). The problem is of course that NHibernate adds it's own sort of spells and rituals to the mix that you have to learn. These spells and rituals also can blowup in your face in a different manner then what you might be used to from ADO spell casting. So there is a learning curve in order to gain easy connection/transaction managment, object change tracking, query batching, non-magic string statically typed queries, sophisticated mapping maintained in a single location, lazy loading, and the ability to have a fuller more meaningful object model.
Now this is with NHibernate which is trying to support the abilities of mapping a fuller object model that is completely independent of the database schema. If you are learning an ORM that went along with a more ActiveRecord pattern then it's probably much easier to use. Generally the easier it is to use though the less flexible so you could run into problems down the run, but you application may never need that. Going with straight ADO will probably be easier to write and get traction when you don't know an ORM, but now you are managing everything yourself. Even if the code is generated it's still code you have to maintain. Naturally your application's DAL and database may never change so managing all that manually may never come into effect.
There is of course the loss of performance and the added overhead to using an ORM. I really don't think this is a problem in our world. ORMs can help optimize database access, in all seriousness, but then you may be biting the bullet on CPU cycles and memory, but that's what we have the most of anyway. Of course there are system/architecture designs that take care of most bottlenecks.
You also have less transparency with an ORM over ADO and SQL. The ORM has to interpret your query and generate the SQL in order to take full advantage of its mappings. You can run into problems of debugging problems because you didn't realize the ORM was going to doing something. This goes back to the learning curve that can be involved for a team, but I rather dislike second guessing myself when I just want to rename or change the mapping for a property.
I think I have hit the majority of concerns with using an ORM and I'll restate my opinion here with a bit more explanation.
I personally find it hard to think of a project where I wouldn't be using an ORM of some kind. This does not mean that you get to avoid learning about databases and SQL. That complexity is there and constant, but it does mean that you get to avoid writing mapping code, casting the spells around ADO (or whatever framework library you have), have to write your own change tracking for dynamic updates, lazy loading, working with dummy objects and more procedural style code, and others.
That last one about procedural code could be a whole other post, but I think that when it's difficult to create and map a fuller object model, developers will create a dummy object model, and that leads to procedural code. I think most of us understand the side effects of medium+ amounts of procedural code (hard to maintain, easy to make mistakes).
So what do you guys think about ORMs and their use? Certainly we all want to be pragmatic, but, unless the project is very small, I find it hard to not think about using one. ORMs seem to becoming like an IoC container for me. This might make it hard for me to gel well with some teams though.