基于struts,spring,ibatis的项目设计及包路径规划,domain object以及相关的讨论

March 31, 2010 | tags        | views
Comments 0

config、sqlmap、domain、dao、sqlmapdao、service、form、action、common、util、filter、exception、test

config用于放置spring及ibatis的配置文件

sqlmap是数据表对应的映射文件，与domain中的字段一一对应。

dao是数据访问接口。

sqlmapdao是dao的实 现。

service是对外提供的方法。

form是页面与action的数据传输及验证通道。

action是Struts的动作类

在最近的围绕domain object的讨论中浮现出来了三种模型，(还有一些其他的旁枝，不一一分析了)，经过一番讨论，各种问题逐渐清晰起来，在这里我试图做一个总结，便于大 家了解和掌握。



第一种模型：只有getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。下面用举一个具体的代码来说明，代码来自Hibernate的caveatemptor，但经过我的改写：



一个实体类叫做Item，指的是一个拍卖项目


一个DAO接口类叫做ItemDao


一个DAO接口实现类叫做ItemDaoHibernateImpl


一个业务逻辑类叫做ItemManager(或者叫做ItemService)



Java 代码
  1. public class Item implements Serializable {  
  2.     private Long id = null;  
  3.     private int version;  
  4.     private String name;  
  5.     private User seller;  
  6.     private String description;  
  7.     private MonetaryAmount initialPrice;  
  8.     private MonetaryAmount reservePrice;  
  9.     private Date startDate;  
  10.     private Date endDate;  
  11.     private Set categorizedItems = new HashSet();  
  12.     private Collection bids = new ArrayList();  
  13.     private Bid successfulBid;  
  14.     private ItemState state;  
  15.     private User approvedBy;  
  16.     private Date approvalDatetime;  
  17.     private Date created = new Date();  
  18.     //  getter/setter方法省略不写，避免篇幅太长  
  19. }  


Java 代码
  1. public interface ItemDao {  
  2.     public Item getItemById(Long id);  
  3.     public Collection findAll();  
  4.     public void updateItem(Item item);  
  5. }  


ItemDao定义持久化操作的接口，用于隔离持久化代码。



Java 代码
  1. public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport {  
  2.     public Item getItemById(Long id) {  
  3.         return (Item) getHibernateTemplate().load(Item.class, id);  
  4.     }  
  5.     public Collection findAll() {  
  6.         return (List) getHibernateTemplate().find("from Item");  
  7.     }  
  8.     public void updateItem(Item item) {  
  9.         getHibernateTemplate().update(item);  
  10.     }  
  11. }  

ItemDaoHibernateImpl完成具体的持久化工作，请注意，数据库资源的获取和释放是在ItemDaoHibernateImpl 里面处理的，每个DAO方法调用之前打开Session，DAO方法调用之后，关闭Session。(Session放在ThreadLocal中，保证 一次调用只打开关闭一次)



Java 代码
  1. public class ItemManager {  
  2.     private ItemDao itemDao;  
  3.     public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}  
  4.     public Bid loadItemById(Long id) {   
  5.         itemDao.loadItemById(id);  
  6.     }  
  7.     public Collection listAllItems() {  
  8.         return  itemDao.findAll();  
  9.     }  
  10.     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,  
  11.                         Bid currentMaxBid, Bid currentMinBid) throws BusinessException {  
  12.             if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {  
  13.         throw new BusinessException("Bid too low.");  
  14.     }  
  15.       
  16.     // Auction is active  
  17.     if ( !state.equals(ItemState.ACTIVE) )  
  18.         throw new BusinessException("Auction is not active yet.");  
  19.       
  20.     // Auction still valid  
  21.     if ( item.getEndDate().before( new Date() ) )  
  22.         throw new BusinessException("Can't place new bid, auction already ended.");  
  23.       
  24.     // Create new Bid  
  25.     Bid newBid = new Bid(bidAmount, item, bidder);  
  26.       
  27.     // Place bid for this Item  
  28.     item.getBids().add(newBid);  
  29.     itemDao.update(item);     //  调用DAO完成持久化操作  
  30.     return newBid;  
  31.     }  
  32. }  



事务的管理是在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 代码
  1. public class Item implements Serializable {  
  2.     //  所有的属性和getter/setter方法同上，省略  
  3.     public Bid placeBid(User bidder, MonetaryAmount bidAmount,  
  4.                         Bid currentMaxBid, Bid currentMinBid)  
  5.         throws BusinessException {  
  6.       
  7.         // Check highest bid (can also be a different Strategy (pattern))  
  8.         if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {  
  9.             throw new BusinessException("Bid too low.");  
  10.         }  
  11.       
  12.         // Auction is active  
  13.         if ( !state.equals(ItemState.ACTIVE) )  
  14.             throw new BusinessException("Auction is not active yet.");  
  15.       
  16.         // Auction still valid  
  17.         if ( this.getEndDate().before( new Date() ) )  
  18.             throw new BusinessException("Can't place new bid, auction already ended.");  
  19.       
  20.         // Create new Bid  
  21.         Bid newBid = new Bid(bidAmount, this, bidder);  
  22.       
  23.         // Place bid for this Item  
  24.         this.getBids.add(newBid);  // 请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生依赖！  
  25.       
  26.         return newBid;  
  27.     }  
  28. }  


竞标这个业务逻辑被放入到Item中来。请注意this.getBids.add(newBid);  如果没有Hibernate或者JDO这种O/R Mapping的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item里面不能去调用ItemDAO，对ItemDAO产生依赖！



ItemDao和ItemDaoHibernateImpl的代码同上，省略。



Java 代码
  1. public class ItemManager {   
  2.     private ItemDao itemDao;   
  3.     public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}   
  4.     public Bid loadItemById(Long id) {   
  5.         itemDao.loadItemById(id);   
  6.     }   
  7.     public Collection listAllItems() {   
  8.         return  itemDao.findAll();   
  9.     }   
  10.     public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,   
  11.                             Bid currentMaxBid, Bid currentMinBid) throws BusinessException {   
  12.         item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid);  
  13.         itemDao.update(item);    // 必须显式的调用DAO，保持持久化  
  14.     }  
  15. }  


在第二种模型中，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 代码
  1. public class Item implements Serializable {  
  2.     //  所有的属性和getter/setter方法都省略  
  3.    private static ItemDao itemDao;  
  4.     public void setItemDao(ItemDao itemDao) {this.itemDao = itemDao;}  
  5.       
  6.     public static Item loadItemById(Long id) {  
  7.         return (Item) itemDao.loadItemById(id);  
  8.     }  
  9.     public static Collection findAll() {  
  10.         return (List) itemDao.findAll();  
  11.     }  
  12.   
  13.     public Bid placeBid(User bidder, MonetaryAmount bidAmount,  
  14.                     Bid currentMaxBid, Bid currentMinBid)  
  15.     throws BusinessException {  
  16.       
  17.         // Check highest bid (can also be a different Strategy (pattern))  
  18.         if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {  
  19.             throw new BusinessException("Bid too low.");  
  20.         }  
  21.           
  22.         // Auction is active  
  23.         if ( !state.equals(ItemState.ACTIVE) )  
  24.             throw new BusinessException("Auction is not active yet.");  
  25.           
  26.         // Auction still valid  
  27.         if ( this.getEndDate().before( new Date() ) )  
  28.             throw new BusinessException("Can't place new bid, auction already ended.");  
  29.           
  30.         // Create new Bid  
  31.         Bid newBid = new Bid(bidAmount, this, bidder);  
  32.           
  33.         // Place bid for this Item  
  34.         this.addBid(newBid);  
  35.         itemDao.update(this);      //  调 用DAO进行显式持久化  
  36.         return newBid;  
  37.     }  
  38. }  


在这种模型中，所有的业务逻辑全部都在Item中，事务管理也在Item中实现。

在上面三种模型之外，还有很多这三种模型的变种，例如partech的模型就是把第二种模型中的DAO和Manager三个类合并为一个类后形成的模型； 例如frain....(id很长记不住)的模型就是把第三种模型的三个类完全合并为一个单类后形成的模型；例如Archie是把第三种模型的Item又 分出来一些纯数据类(可能是，不确定)形成的一个模型。

但是不管怎么变，基本模型归纳起来就是上面的三种模型，下面分别简单评价一下：

第一种模型绝大多数人都反对，因此反对理由我也不多讲了。但遗憾的是，我观察到的实际情形是，很多使用Hibernate的公司最后都是这种模 型，这里面有很大的原因是很多公司的技术水平没有达到这种层次，所以导致了这种贫血模型的出现。从这一点来说，Martin Fowler的批评声音不是太响了，而是太弱了，还需要再继续呐喊。

第二种模型就是Martin Fowler一直主张的模型，实际上也是我一直在实际项目中采用这种模型。

不过我觉得这种模型仍然不够完美，因为你还是需要一个业务逻辑层来封装所有的domain logic，这显得非常罗嗦，并且业务逻辑对象的接口也不够稳定。如果不考虑业务逻辑对象的重用性的话(业务逻辑对象的可重用性也不可能好)，很多人干脆 就去掉了xxxManager这一层，在Web层的Action代码直接调用xxxDao，同时容器事务管理配置到Action这一层上来。 Hibernate的caveatemptor就是这样架构的一个典型应用。

第三种模型是我很反对的一种模型，这种模型下面，Domain Object和DAO形成了双向依赖关系，无法脱离框架测试，并且业务逻辑层的服务也和持久层对象的状态耦合到了一起，会造成程序的高度的复杂性，很差的 灵活性和糟糕的可维护性。也许将来技术进步导致的O/R Mapping管理下的domain object发展到足够的动态持久透明化的话，这种模型才会成为一个理想的选择。就像O/R Mapping的流行使得第二种模型成为了可能(O/R Mapping流行以前，我们只能用第一种模型，第二种模型那时候是不现实的)。

Robbin总结的三点模型，我1、2用过，所味的第3点还无福消受啊

一、关于第一种模型我在一个实际项目中做过这样的设计，给我的感觉不是很好，主要有以下几点：
  《1》要写太多的贫血类，其实可以做一个工具来自动生成，也不错。
   《2》业务逻辑感觉不能很好的得到体现，这样增加了BussImp类的复杂度， 且许多操作是不应该由BussImp来承担， 但也有个好处那就是设计相对的容易些
    《3》这不是OO的正统设计，这是受Boost的影响
二、至于第二种模型是我一直都在用的，这种模型对设计人员的要求相对的要高，为什么？那是因为对 ItemClass 要比以前更难以把握，其实设计就是归类，但就是这个归类就不那么的简单，且每个人都有自己的归类方法，很难形成统一。

转自：http://www.javaeye.com/topic/11712



文章本月排行 文章本年排行
   



发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。