(事先声明，我对.Net非常之不熟悉，同时英文水平很差，所以我所理解的各个O/R Mapping产品特性也许是错误的，希望有人能够指证出来，也好让我改正错误，所以这些写出来的东西可能是错的，但是说错并不可怕，只要你说过了)
O/R Mapping在Java世界是尽人皆知，而.Net下也越来越被大家所关注，同时这类产品也已经出来了不少，我想就某些比较流行的方案说一下它们各自的特性和缺点，同时会穿插我本来对O/R Mapping的理解和期望，同时也表示我正式开始.Net下的软件开发。
我也许会继续写下去，也许不会，看时间而定了，我主要比较的特性分以下几个方面：
DB->Class or Class->DB
多数据库支持
Mapping方式
关系映射
实体类的复杂性
实体集合返回方式
Null值处理
Lazy-loading
Session管理
事务处理
Cache
OQL语言支持
Criteria查询构造
部分属性查询和表达式构造
数据绑定支持
BLOB支持
其它数据对象的映射支持(sp、view)
计算字段的支持
批量更新和增量更新操作的支持
大家最近谈得比较多的XPO，那么就它先吧。(未完，因为要睡觉了)
O/R Mapping之XPO
出品:Dev Express
最新版本：1.5
1、DB->Class or Class->DB
XPO两者都支持，但它更像是一个Class->DB的持久化方案，因为它的session支持根据class直接生成数据库schema。
2、多数据库支持
内部实现中XPO同样抽象出了数据访问层，理论上它可以支持任何数据库，虽然目前只支持MSSQL和Access。
但是从它定义的ConnectionProvider来看，它对数据库的特性支持非常有限。
3、Mapping方式
因为是.Net下的持久层，所以XPO也不例外地使用了自定义属性来处理映射，同时支持最小情况下的无须任何属性便可完成映射(当时实体类要继承基类)。它的映射可以支持：名称映射、索引建立、选择性映射、关系映射、实体类继承、级联更新、迟加载、锁定类型、NULL处理等功能，基本上可以满足CRUD和类之间的关系维护。因为XPO偏重的是Class->DB，所以它并没有提供类代码生成器。
4、实体类的复杂性
实体类必须从XPO的实体基类上继承，以实现实体类的状态管理，这样做的好处是可以直接调用实体类的save来实现持久保存数据。XPO有一个默认的session，而且当实体类没有明确指定session时，一切对象的保存都会调用默认的session.save来完成，而这个默认的session又有一个默认的Access的ConnectionProvider，它可以自动完成数据库Schema的构造工作，所以有时候XPO的tutorial看上去就是那么的"简单"：定义实体类->创建实体类->调用实体类的Save。
5、CRUD
这是O/R Mapping最基本也是使用得最多的一个功能了，XPO在这一点上做得还算是中规中矩。但是：
(1)它因为没有使用代理机制拦截属性赋值，所以它无法实现只对修改过的值进行操作，在保存时所有可持久化属性都将被更新到数据库中，这点在多点并发情况下是致命的。
(2)它居然无法通过主键来retrive数据，只能通过XPCollection或XPCursor来获得，每次都写Critiria来查询数据，多累啊!(经Yok指证，可以通过session.getobjectbykey实现)
6、实体集合返回方式
Dev在这个处理和我一直以来的处理方式的表现形式非常相似，它利用XPCollection和XPCursor来实现实体集合和数据集的封装，前者是一个”重量级“的集合，但在这个集合中的数据都会一直存在缓冲中，并且支持批量操作；而XPCursor就比较轻了，它可以通过PageSize来设定页大小，从而每次只装载当前页到一个XPCollection中以供遍历。
为什么我只说是表现形式和我的处理方式相似呢，因为我在处理数据集封装时是一直重用一个实体类实例，但是XPO因为需要维护内存对象，抑或是.Net下对象开销比较便宜吧。