Though I have a different focus at the moment, something I keep in the back of my head is DAO and ORM material as I’ll eventually be embarking on a very data heavy project. Without getting into specifics, it would seem logical that an ORM implementation to access the data in the aforementioned project would be somewhat beneficial because the data involved seems to be pretty easy to model and seem to be simple is-a nouns such as “Address”, “Person”, etc. However, I find myself fairly resistant to try and represent said data as objects because of the complexity involved, the lack of control over the underlying structure of the data, trying to combine many disparate sources, etc.
Along the same vein, I just happened to come across a blog post from Ted Neward describing ORM as the Vietnam of Computer Science while trying to research Java performance on dual-core processors:
In the case of Vietnam, the United States political and military apparatus was faced with a deadly form of the Law of Diminishing Returns. In the case of automated Object/Relational Mapping, it’s the same concern–that early successes yield a commitment to use O/R-M in places where success becomes more elusive, and over time, isn’t a success at all due to the overhead of time and energy required to support it through all possible use-cases. In essence, the biggest lesson of Vietnam–for any group, political or otherwise–is to know when to “cut bait and run”, as fishermen say.
It’s a pretty lengthly read, but very well explained.
Like any technology, everything looks like a nail when you have a hammer, and I think ORM is one of those tools that people smash bananas with from time to time. The majority of the time I think it’s a good way to go with your data model, but there are plenty of exceptions.