John Cardinal wrote:
The reason being is that it's not really ORM at all, it's TOM Table Object Mapping and a single table never properly represents the complexity of a real world object.
It depends on your approach. For example, I use NHibernate for almost all of my projects. With NHibernate, you can start from tables and generate objects or you can start with objects and generate tables. The former approach generally leads to a TOM feeling, but the latter approach is where the power of ORM lies, imo. I start a new project by modeling the problem with objects - as complex as needed for the task at hand. I then use NHibernate to handle all of the database persistence. While NHibernate does have its limitations, I find that I'm generally able to map my real-world objects quite nicely. While a single table rarely represents the complexity of a real-world object, multiple tables and the relationships between those tables can. NHibernate is great because I don't have to write/maintain any SQL - but I do have the flexibility if needed. It includes a caching mechanism that is configurable and provides lazy loading. In short, once I create my objects, my DAL comes basically for free. The tradeoff? As has been mentioned, there is a learning curve and you have to evaluate whether the increase in 'intellectual complexity' is worth the benefits that ORM provides.