DAO与SERVICE

DAO:::::DAO实现对数据库的操作.

SERVICE::::::Service实现业务逻辑的封装，数据库操作只是业务逻辑的一部分而已。

但是在实际应用中，建议使用Service+DAO，看似麻烦些，但分层能相对清晰一点。

总之,我还是很喜欢把DAO和SERVICE分开的。这样起码以后容易扩展并且看起来逻辑清晰.

看过的一篇帖子说:比如现在用hibernate 以后可能改为jdbc或者其他的也比较方便,SERVICE是单纯的进行业务逻辑处理调用DAO来持久数据,所以DAO和SERVICE还是应该要独立的！

以下是我看到的一个帖子，总结的很好。做为收藏．．．．．

第二种模型，也就是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. } 

<script>render_code();</script>

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

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. } 

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. } 

<script>render_code();</script>

在第二种模型中，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框架之外独立存在。