ORM到底是O->R 还是 R->O

这个问题其实本来无所谓，考虑一下也不浪费太多时间。

先考虑一个只有一个模块的系统，这样可以屏蔽很多干扰，假设这是一个库存管理模块，显而易见有两个核心实体：品种及库存，再考虑品种的设计，我们又可以得出分类这样一个字典表。在这个分析过程中，实体是表还是对象因人而异。我属于那种后来学习直拍反打的选手，因此习惯上直接把实体建成了数据库表。但对于类似王皓这样的不会推挡只会反打的选手，那就一定是对象了。
从O->R有一些好处就是在分析设计的时候有了更细腻的方法（直拍反打称为手法）对设计进行细嚼慢咽，但是同时也消耗了更多的时间。
从R->O的好处是你直接与数据库进行了对话，因此你了解它的实际构造。在需要的时候将R变为O来操作，你仍然可以使用你所熟悉的SQL对数据库进行直接了当的操作。

再考虑有多个模块的系统，假设系统的模块已经划分妥当（不在本文讨论范围之内），从O出发的选手有很多的方法和理论来实现模块之间的松耦合。而从R出发的选手则只有一个方法，即为两个模块建立R，而这个R最好只建立在一张表上。


因此，考虑到OODB的局限性，如果你是老选手，你仍然具有优势，但这个优势能保持多久则很难讲。