近日 有关o/r m的讨论突然多了起来. 在这里觉得有必要澄清一些概念, 免的大家讨论来讨论去, 才发现最根本的理解有问题.本文并不保证所有观点正确, 只是个人在某一特定时期的理解.
1. 何谓Entity?
实体(类似于j2ee中的Entity Bean)通常指一个承载数据的对象, 但是注意它也是可以有行为的! 只不过它的行为一般只操作自身的数据. 比如下面这个例子:
class Person
{
string firstName; string lastName; public void GetName()
{
return lastName+firstName;
} 
}
GetName就是它的一个行为.
2 何谓Domain Object?
对象最重要的特性在于它拥有行为. 仅仅拥有数据,你可以称它为对象, 但是它却失去它最重要的灵魂.
class Person{ string firstName; string lastName; Role role; int baseWage; public void GetSalary() { return baseWage*role.GetFactory(); } }
这样需要和别的对象(不是Value Object)打交道的对象,我就不再称其为实体. 领域模型就是指由这些具有业务逻辑的对象构成的模型.
3. E/R M or O/R M?!!
仔细想想我们为什么需要o/r m,无非是想利用oo的多态来处理复杂的业务逻辑, 而不是靠一堆的if else.
而现在在很多人的手上o/r m全变成了e/r m.他们不考虑对象的行为, 而全关注于如何保存数据.这样也难怪他们会产生将CRUD这些操作放入对象中的念头. 如果你不能深刻理解oo, 那么我不推荐你使用o/r m, Table Gateway, Row Gateway才是你想要的东西.
作为一个O/R M框架，很重要的一点就是实现映射的透明性（Transparent），比较显著的特点就是在代码中我们是看不到SQL语句的（框架自动生成了）,但是这并不是透明性的实质,详见Enterprise Persistence Design,这里所指的O/R M就是类似于此的框架.
4. POEAA中的相关概念
很多次发现有人错用其中的概念, 这里顺便总结一下:
1. Table Gateway
以表为单位的实体集合,基本没有行为,只有CRUD操作.
2. Row Gateway
以行为单位的实体,基本没有行为,只有CRUD操作.
3. Active Record
以行为单位的实体,拥有一些基本的操作自身数据的行为(如上例中的GetName),同时包含有CRUD操作.
其实Active Record最符合某些简单的需求, 接近于E/R m.
通常也有很多人把它当作O/R m.不过需要注意的是Active Record中是充满了SQL语句的(不像orm的SQL透明), 所以有人想起来利用O/R m来实现"Active Record", 虽然在他们眼里看起来很方便, 其实根本就是返祖.
用CodeGenerator来实现Active Record也许是一个比较好的方法.
4. Data Mapper
这才是真正的O/R m,Hibernate等等工具的目标.
5.O/R M需要关注的地方 (希望大家帮忙完善一下)
1. 关联以及与此相关的Lazy Load, O/R M是如何管理类之间的关联.当然这不仅于O/R M有关与设计者的设计水平也有很大关系.
2. O/R M对继承关系的处理.
3. O/R M对事务的支持.
4. O/R M对查询的支持.
以上观点仅属个人意见, 不过在大家讨论有关O/R M之前, 希望先就一些基本概念达成共识, 不然讨论下去会越离越远.
(建议: 如果对oo以及dp没有一定程度的了解, 最好别使用o/r m, dataset 加上codesmith或许是更好的选择)
