O/R Mapping - What to look for
When making (or are on the verge thereof) decisions about picking an ORM (object-to-relational-database mapper), determine first what you need:
1. Performance: If this is an issue, properly stress test the code that the tool generates or the library you're going to reuse, using a sample project. Do this upfront (if possible - to be honest, the no-evaluation-version-black-box-approach gives me the ...) and most importantly test all features you require.
2. Features: Determine what features you want. To name a few:
a. Datasource independence: going to different datasources vs. going to one, or switching datasources over time.
b. Lazy load, object registry, ...: Read Patterns of Enterprise Application Architecture for more insight on these (and other) patterns and if they are of any importance to you. The book is very insightful(but not complete, mind you).
c. "Pluggable" creation mechanism: How do you want your objects to get created? Using a base class, reflection, serialization, obligatory interface, pre-compilation code injection, post-compilation code-injection via emission.
d. Separation of tiers and layering preferences: Determine how you want to work with tiers and layers (drawing helps here) and compare how the tool/lib does it.
e. Transaction control/Unit of work: To COM+ or to roll "their/your own". Mainly a choice of technology.
f. Mapping: Do you need 1..1 or 1..N or N..M (or all or some)? How are collections and dependencies aka associations handled (check out the update mechanism == the harder part)?
g. Query facilities: Write SQL or some OQL like incarnation? Beware of this in light of point "a" and "b".
We (at work that is) made our own datalayer, because we needed our business layer to be totally unaware of persistence, which I found in none of today's products/projects.
One particular aspect we introduced was the abstraction of SQL into objects. All of our queries are made by building them via objects. We never write any SQL anymore (at least not in the syntactical sense). Instead the datalayer translates those objects into the DML of the datasource. That would be a nice open-source project (sigh, if only corporate regulations let me ...).
Important things I seek in a datalayer is the limited number of DML statements it generates, the lesser it demands from my business layer the better, the white-box approach, intelligent caching (and the obvious ones like transparency, ease of use, robustness, ...).