DAO:::::DAO实现对数据库的操作.
SERVICE::::::Service实现业务逻辑的封装，数据库操作只是业务逻辑的一部分而已。
但是在实际应用中，建议使用Service+DAO，看似麻烦些，但分层能相对清晰一点。
总之,我还是很喜欢把DAO和SERVICE分开的。这样起码以后容易扩展并且看起来逻辑清晰.
看过的一篇帖子说:比如现在用hibernate 以后可能改为jdbc或者其他的也比较方便,SERVICE是单纯的进行业务逻辑处理调用DAO来持久数据,所以DAO和SERVICE还是应该要独立的！
http://www.iteye.com/topic/11712
以下是我看到的一个帖子，总结的很好。做为收藏．．．．．
第二种模型，也就是Martin Fowler指的rich domain object是下面这样子的：
一个带有业务逻辑的实体类，即domain object是Item
一个DAO接口ItemDao
一个DAO实现ItemDaoHibernateImpl
一个业务逻辑对象ItemManager
java 代码
1. public class Item implements
2. // 所有的属性和getter/setter方法同上，省略
3. public
4. Bid currentMaxBid, Bid currentMinBid)
5. throws
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
14. throw new BusinessException("Auction is not active yet.");
15.
16. // Auction still valid
17. if ( this.getEndDate().before( new
18. throw new BusinessException("Can't place new bid, auction already ended.");
19.
20. // Create new Bid
21. new Bid(bidAmount, this, bidder);
22.
23. // Place bid for this Item
24. this.getBids.add(newBid); // 请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生依赖！
25.
26. return
27. }
28. }
<script>render_code();</script>
竞标这个业务逻辑被放入到Item中来。请注意this.getBids.add(newBid); 如果没有Hibernate或者JDO这种O/R Mapping的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item里面不能去调用ItemDAO，对ItemDAO产生依赖！
java 代码
1. public interface
2. public
3. public
4. public void
5. }
ItemDao定义持久化操作的接口，用于隔离持久化代码。
java 代码
1. public class ItemDaoHibernateImpl implements ItemDao extends
2. public
3. return (Item) getHibernateTemplate().load(Item.class, id);
4. }
5. public
6. return (List) getHibernateTemplate().find("from Item");
7. }
8. public void
9. getHibernateTemplate().update(item);
10. }
11. }
java 代码
1. public class
2. private
3. public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}
4. public
5. itemDao.loadItemById(id);
6. }
7. public
8. return
9. }
10. public
11. throws
12. item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid);
13. // 必须显式的调用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框架之外独立存在。
