在最近的围绕domain
object的讨论中浮现出来了三种模型，(还有一些其他的旁枝，不一一分析了)，经过一番讨论，各种问题逐渐清晰起来，在这里我试图做一个总结，便于大家了解和掌握。
第一种模型：只有getter/setter方法的纯数据类，所有的业务逻辑完全由business
object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain
object”。下面用举一个具体的代码来说明，代码来自Hibernate的caveatemptor，但经过我的改写：
一个实体类叫做Item，指的是一个拍卖项目
一个DAO接口类叫做ItemDao
一个DAO接口实现类叫做ItemDaoHibernateImpl
一个业务逻辑类叫做ItemManager(或者叫做ItemService)
|
java代码:
|
|
public
class Item implementsSerializable{
privateLong id = null;
privateint version;
privateString name;
private User seller;
privateString description;
private MonetaryAmount
initialPrice;
private MonetaryAmount
reservePrice;
privateDate startDate;
privateDate endDate;
privateSet categorizedItems = newHashSet();
privateCollection bids = newArrayList();
private
Bid successfulBid;
private ItemState state;
private
User approvedBy;
privateDate approvalDatetime;
privateDate created = newDate();
//
getter/setter方法省略不写，避免篇幅太长
}
|
|
java代码:
|
|
public
interface ItemDao {
public Item
getItemById(Long id);
publicCollection findAll();
publicvoid
updateItem(Item item);
}
|
ItemDao定义持久化操作的接口，用于隔离持久化代码。
|
java代码:
|
|
public
class
ItemDaoHibernateImpl implements ItemDao extends
HibernateDaoSupport {
public Item
getItemById(Long id){
return(Item) getHibernateTemplate().load(Item.class, id);
}
publicCollection findAll(){
return(List) getHibernateTemplate().find("from
Item");
}
publicvoid updateItem(Item item){
getHibernateTemplate().update(item);
}
}
|
ItemDaoHibernateImpl完成具体的持久化工作，请注意，数据库资源的获取和释放是在ItemDaoHibernateImpl
里面处理的，每个DAO方法调用之前打开Session，DAO方法调用之后，关闭Session。(Session放在ThreadLocal中，保证一次调用只打开关闭一次)
|
java代码:
|
|
public
class ItemManager {
private ItemDao itemDao;
publicvoid
setItemDao(ItemDao itemDao){
this.itemDao = itemDao;}
public Bid
loadItemById(Long id){
itemDao.loadItemById(id);
}
publicCollection listAllItems(){
return itemDao.findAll();
}
public Bid placeBid(Item item, User bidder, MonetaryAmount
bidAmount,
Bid currentMaxBid, Bid
currentMinBid)throws BusinessException
{
if(currentMaxBid != null &&
currentMaxBid.getAmount().compareTo(bidAmount) > 0){
throw new
BusinessException("Bid too low.");
}
// Auction is active
if( !state.equals(ItemState.ACTIVE))
throw new
BusinessException("Auction is not active yet.");
// Auction still valid
if( item.getEndDate().before(newDate()))
throw new
BusinessException("Can't place new bid, auction already
ended.");
// Create new Bid
Bid newBid =
new Bid(bidAmount, item, bidder);
// Place bid for this Item
item.getBids().add(newBid);
itemDao.update(item);
// 调用DAO完成持久化操作
return newBid;
}
}
|
事务的管理是在ItemManger这一层完成的，ItemManager实现具体的业务逻辑。除了常见的和CRUD有关的简单逻辑之外，这里还有一个placeBid的逻辑，即项目的竞标。
以上是一个完整的第一种模型的示例代码。在这个示例中，placeBid，loadItemById，findAll等等业务逻辑统统放在ItemManager中实现，而Item只有getter/setter方法。
第二种模型，也就是Martin Fowler指的rich domain object是下面这样子的：
一个带有业务逻辑的实体类，即domain object是Item
一个DAO接口ItemDao
一个DAO实现ItemDaoHibernateImpl
一个业务逻辑对象ItemManager
|
java代码:
|
|
public
class Item implementsSerializable{
// 所有的属性和getter/setter方法同上，省略
public Bid
placeBid(User bidder, MonetaryAmount
bidAmount,
Bid currentMaxBid, Bid currentMinBid)
throws BusinessException
{
// Check highest bid (can also be a different
Strategy (pattern))
if(currentMaxBid != null &&
currentMaxBid.getAmount().compareTo(bidAmount) > 0){
throw new
BusinessException("Bid too low.");
}
// Auction is active
if( !state.equals(ItemState.ACTIVE))
throw new
BusinessException("Auction is not active yet.");
// Auction still valid
if( this.getEndDate().before(newDate()))
throw new
BusinessException("Can't place new bid, auction already
ended.");
// Create new Bid
Bid newBid = new
Bid(bidAmount, this, bidder);
// Place bid for this Item
this.getBids.add(newBid); //
请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生依赖！
return newBid;
}
}
|
竞标这个业务逻辑被放入到Item中来。请注意this.getBids.add(newBid);
如果没有Hibernate或者JDO这种O/R
Mapping的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item里面不能去调用ItemDAO，对ItemDAO产生依赖！
ItemDao和ItemDaoHibernateImpl的代码同上，省略。
|
java代码:
|
|
public
class ItemManager {
private ItemDao itemDao;
publicvoid
setItemDao(ItemDao itemDao){
this.itemDao = itemDao;}
public Bid
loadItemById(Long id){
itemDao.loadItemById(id);
}
publicCollection listAllItems(){
return itemDao.findAll();
}
public Bid placeBid(Item item, User bidder, MonetaryAmount
bidAmount,
Bid currentMaxBid, Bid
currentMinBid)throws BusinessException
{
item.placeBid(bidder, bidAmount, currentMaxBid,
currentMinBid);
itemDao.update(item);
// 必须显式的调用DAO，保持持久化
}
}
|
在第二种模型中，placeBid业务逻辑是放在Item中实现的，而loadItemById和findAll业务逻辑是放在
ItemManager中实现的。不过值得注意的是，即使placeBid业务逻辑放在Item中，你仍然需要在ItemManager中简单的封装一层，以保证对placeBid业务逻辑进行事务的管理和持久化的触发。
这种模型是Martin Fowler所指的真正的domain
model。在这种模型中，有三个业务逻辑方法：placeBid，loadItemById和findAll，现在的问题是哪个逻辑应该放在Item
中，哪个逻辑应该放在ItemManager中。在我们这个例子中，placeBid放在Item中(但是ItemManager也需要对它进行简单的封装)，loadItemById和findAll是放在ItemManager中的。
切分的原则是什么呢？ Rod Johnson提出原则是“case by case”，可重用度高的，和domain
object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在ItemManager中。
我提出的原则是：看业务方法是否显式的依赖持久化。
Item的placeBid这个业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，所以要放在Item中。请注意，如果脱离了Hibernate这个持久化框架，Item这个domain
object是可以进行单元测试的，他不依赖于Hibernate的持久化机制。它是一个独立的，可移植的，完整的，自包含的域对象。
而loadItemById和findAll这两个业务逻辑方法是必须显式的对持久化ItemDao接口产生依赖，否则这个业务逻辑就无法完成。如果你要把这两个方法放在Item中，那么Item就无法脱离Hibernate框架，无法在Hibernate框架之外独立存在。
第三种模型印象中好像是firebody或者是Archie提出的(也有可能不是，记不清楚了)，简单的来说，这种模型就是把第二种模型的domain
object和business object合二为一了。所以ItemManager就不需要了，在这种模型下面，只有三个类，他们分别是：
Item：包含了实体类信息，也包含了所有的业务逻辑
ItemDao：持久化DAO接口类
ItemDaoHibernateImpl：DAO接口的实现类
由于ItemDao和ItemDaoHibernateImpl和上面完全相同，就省略了。
|
java代码:
|
|
public
class Item implementsSerializable{
// 所有的属性和getter/setter方法都省略
privatestatic ItemDao itemDao;
publicvoid
setItemDao(ItemDao itemDao){this.itemDao = itemDao;}
publicstatic Item
loadItemById(Long id){
return(Item) itemDao.loadItemById(id);
}
publicstaticCollection findAll(){
return(List) itemDao.findAll();
}
public Bid placeBid(User bidder, MonetaryAmount bidAmount,
Bid currentMaxBid, Bid currentMinBid)
throws BusinessException
{
// Check highest bid (can also be a different
Strategy (pattern))
if(currentMaxBid != null &&
currentMaxBid.getAmount().compareTo(bidAmount) > 0){
throw new
BusinessException("Bid too low.");
}
// Auction is active
if( !state.equals(ItemState.ACTIVE))
throw new
BusinessException("Auction is not active yet.");
// Auction still valid
if( this.getEndDate().before(newDate()))
throw new
BusinessException("Can't place new bid, auction already
ended.");
// Create new Bid
Bid
newBid = new
Bid(bidAmount, this, bidder);
// Place bid for this Item
this.addBid(newBid);
itemDao.update(this);
// 调用DAO进行显式持久化
return newBid;
}
}
|
在这种模型中，所有的业务逻辑全部都在Item中，事务管理也在Item中实现。
在上面三种模型之外，还有很多这三种模型的变种，例如partech的模型就是把第二种模型中的DAO和
Manager三个类合并为一个类后形成的模型；例如frain....(id很长记不住)的模型就是把第三种模型的三个类完全合并为一个单类后形成的模型；例如Archie是把第三种模型的Item又分出来一些纯数据类(可能是，不确定)形成的一个模型。
但是不管怎么变，基本模型归纳起来就是上面的三种模型，下面分别简单评价一下：
第一种模型绝大多数人都反对，因此反对理由我也不多讲了。但遗憾的是，我观察到的实际情形是，很多使用Hibernate的公司最后都是这种模型，这里面有很大的原因是很多公司的技术水平没有达到这种层次，所以导致了这种贫血模型的出现。从这一点来说，Martin
Fowler的批评声音不是太响了，而是太弱了，还需要再继续呐喊。
第二种模型就是Martin
Fowler一直主张的模型，实际上也是我一直在实际项目中采用这种模型。我没有看过Martin的POEAA，之所以能够自己摸索到这种模型，也是因为从02年我已经开始思考这个问题并且寻求解决方案了，但是当时没有看到Hibernate，那时候做的一个小型项目我已经按照这种模型来做了，但是由于没有O/R
Mapping的支持，写到后来又不得不全部改成贫血的domain
object，项目做完以后再继续找，随后就发现了Hibernate。当然，现在很多人一开始就是用Hibernate做项目，没有经历过我经历的那个阶段。
不过我觉得这种模型仍然不够完美，因为你还是需要一个业务逻辑层来封装所有的domain
logic，这显得非常罗嗦，并且业务逻辑对象的接口也不够稳定。如果不考虑业务逻辑对象的重用性的话(业务逻辑对象的可重用性也不可能好)，很多人干脆就去掉了xxxManager这一层，在Web层的Action代码直接调用xxxDao，同时容器事务管理配置到Action这一层上来。
Hibernate的caveatemptor就是这样架构的一个典型应用。
第三种模型是我很反对的一种模型，这种模型下面，Domain
Object和DAO形成了双向依赖关系，无法脱离框架测试，并且业务逻辑层的服务也和持久层对象的状态耦合到了一起，会造成程序的高度的复杂性，很差的灵活性和糟糕的可维护性。也许将来技术进步导致的O/R
Mapping管理下的domain object发展到足够的动态持久透明化的话，这种模型才会成为一个理想的选择。就像O/R
Mapping的流行使得第二种模型成为了可能(O/R Mapping流行以前，我们只能用第一种模型，第二种模型那时候是不现实的)。
既然大家都统一了观点，那么就有了一个很好的讨论问题的基础了。Martin Fowler的Domain
Model，或者说我们的第二种模型难道是完美无缺的吗？当然不是，接下来我就要分析一下它的不足，以及可能的解决办法，而这些都来源于我个人的实践探索。
在第二种模型中，我们可以清楚的把这4个类分为三层：
1、实体类层，即Item，带有domain logic的domain
object
2、DAO层，即ItemDao和ItemDaoHibernateImpl，抽象持久化操作的接口和实现类
3、业务逻辑层，即ItemManager，接受容器事务控制，向Web层提供统一的服务调用
在这三层中我们大家可以看到，domain
object和DAO都是非常稳定的层，其实原因也很简单，因为domain object是映射数据库字段的，数据库字段不会频繁变动，所以domain
object也相对稳定，而面向数据库持久化编程的DAO层也不过就是CRUD而已，不会有更多的花样，所以也很稳定。
问题就在于这个充当business workflow facade的业务逻辑对象，它的变动是相当频繁的。业务逻辑对象通常都是无状态的、受事务控制的、Singleton类，我们可以考察一下业务逻辑对象都有哪几类业务逻辑方法：
第一类：DAO接口方法的代理，就是上面例子中的loadItemById方法和findAll方法。
ItemManager之所以要代理这种类，目的有两个：向Web层提供统一的服务调用入口点和给持久化方法增加事务控制功能。这两点都很容易理解，你不能既给Web层程序员提供xxxManager，也给他提供xxxDao，所以你需要用xxxManager封装xxxDao，在这里，充当了一个简单代理功能；而事务控制也是持久化方法必须的，事务可能需要跨越多个DAO方法调用，所以必须放在业务逻辑层，而不能放在DAO层。
但是必须看到，对于一个典型的web应用来说，绝大多数的业务逻辑都是简单的CRUD逻辑，所以这种情况下，针对每个DAO方法，xxxManager都需要提供一个对应的封装方法，这不但是非常枯燥的，也是令人感觉非常不好的。
第二类：domain
logic的方法代理。就是上面例子中placeBid方法。虽然Item已经有了placeBid方法，但是ItemManager仍然需要封装一下Item的placeBid，然后再提供一个简单封装之后的代理方法。
这和第一种情况类似，其原因也一样，也是为了给Web层提供一个统一的服务调用入口点和给隐式的持久化动作提供事务控制。
同样，和第一种情况一样，针对每个domain logic方法，xxxManager都需要提供一个对应的封装方法，同样是枯燥的，令人不爽的。
第三类：需要多个domain object和DAO参与协作的business
workflow。这种情况是业务逻辑对象真正应该完成的职责。
在这个简单的例子中，没有涉及到这种情况，不过大家都可以想像的出来这种应用场景，因此不必举例说明了。
通过上面的分析可以看出，只有第三类业务逻辑方法才是业务逻辑对象真正应该承担的职责，而前两类业务逻辑方法都是“无奈之举”，不得不为之的事情，不但枯燥，而且令人沮丧。
分析完了业务逻辑对象，我们再回头看一下domain object，我们要仔细考察一下domain
logic的话，会发现domain logic也分为两类：
第一类：需要持久层框架隐式的实现透明持久化的domain
logic，例如Item的placeBid方法中的这一句：
|
java代码:
|
|
this.getBids().add(newBid);
|
上面已经着重提到，虽然这仅仅只是一个Java集合的添加新元素的操作，但是实际上通过事务的控制，会潜在的触发两条SQL：一条是insert一条记录到bid表，一条是更新item表相应的记录。如果我们让Item脱离Hibernate进行单元测试，它就是一个单纯的Java集合操作，如果我们把他加入到Hibernate框架中，他就会潜在的触发两条SQL，这就是隐式的依赖于持久化的domain logic。
特别请注意的一点是：在没有Hibernate/JDO这类可以实现“透明的持久化”工具出现之前，这类domain logic是无法实现的。
对于这一类domain logic，业务逻辑对象必须提供相应的封装方法，以实现事务控制。
第二类：完全不依赖持久化的domain logic，例如readonly例子中的Topic，如下：
|
java代码:
|
|
class Topic {
boolean
isAllowReply(){
Calendar dueDate =
Calendar.getInstance();
dueDate.setTime(lastUpdatedTime);
dueDate.add(Calendar.DATE, forum.timeToLive);
Date now = newDate();
return
now.after(dueDate.getTime());
}
}
|
注意这个isAllowReply方法，他和持久化完全不发生一丁点关系。在实际的开发中，我们同样会遇到很多这种不需要持久化的业务逻辑(主要发生在日期运算、数值运算和枚举运算方面)，这种domain
logic不管脱离不脱离所在的框架，它的行为都是一致的。对于这种domain
logic，业务逻辑层并不需要提供封装方法，它可以适用于任何场合。
posted on 2006-05-30 13:31
混沌中立 阅读(3033)
评论(1) 编辑 收藏 所属分类:
about java & j2ee