Udi Dahan on How-To-Select an O/R Mapping Tool for .NET (2006)

The single most important trap to watch out for when choosing an object-relational mapping tool is "architecture by product." Architecture by product describes a set of symptoms I've seen in many projects, where entire teams spend months agonizing over product comparison tables, debating the importance and rankings of various features. Once the product was chosen, the decision was set in stone and the project's architecture (when there was one) bent itself around the product.

Object-relational mapping is considered an important supporting framework for the Domain Model pattern (a pattern that many have employed successfully), and you really need to understand where object-relational mapping fits into your architecture before you choose a product.

Although architecture by product is a generic trap, the Achilles heel of object-relational mapping is reporting.

I have yet to see an application where some kind of reporting was not required. Reporting does not necessarily begin and end with reports printed in Word or PDF format; the basis of reporting is joining data of differing kinds into a single view-primarily read-only. For some reason, once developers begin using an object-relational mapping tool, all of a sudden they want to use it for everything, reporting included.

The data used in reporting has no connection whatsoever to objects. First of all, it's just data-there's not a single bit of behavior in sight. Secondly, we usually don't need all of the data from the entities involved, just a bit from each of them. The DataTable in .NET suits these needs just fine, not to mention the fact that third-party reporting vendors work well with it. Even though many object-relational mapping tools may enable you to perform complex queries that return objects, in the case of reporting, you just don't need it. That's one feature to take off of your product comparison table.