DAO和Service层

1，dao和service对应
    一般DAO只操作一个POJO对象，因此一个DAO对应一个POJO对象。 Service层是为了处理包含多个POJO对象（即对多个表的数据操作）时，进行事务等管理。所以Service层（其接口的实现类）被注入一个或多个DAO对象，以完成有意义的数据操作。
2, 两种构建业务层的模式探讨是否需要Service层
    模式1是Service + DAO,即DAO中只做CRUD及类似的简单操作(称之为能点,无业务逻辑),Service通过调用一个或多个DAO中的功能点来组合成为业务逻辑。       这种模型业务逻辑放在Service中的,事务管理也在Service中控制。可以直接在Service中控制事务但会引入非业务逻辑代码,Spring的AOP可解决这个问题。
    此模型对某些对象的操作仅仅是简单的CRUD,Service层显得累赘。
    模式2是Service + BO, 而BO = DAO + 业务方法, 在原先DAO的基础上添加业务方法,形成BO对象。BO中的业务方法往往是针对一个实体对象的，如果跨越多个实体对象，则方法应该放在Service中。     
    银行帐户管理系统中，创建帐户这个BO对象，可有修改密码、取钱等业务（只对单个帐户对象进行操作）。若需要添加转账，就应该放在Service中。    
    国家行政机关：粮食局负责收粮，卖种子等，建设部负责审批土地买卖，建设公路等，这都是行政部分份内的事儿。突然某地发了水灾、救灾时需粮食局开仓放粮，建设部修建临时房屋，如何协调两个部门？就需要成立专门的救灾委员会，由救灾委员会出面对两个部分的资源进行调拨。这里两个部分就是BO，而救灾委员会就是Service。
    模式1的在划分Service和DAO时界限清晰，但会带来一些无必要的代码。     
    模式2的划分相对复杂，然而可以提高编码效率。    
    当然小规模的应用中，没有Service，完全是DAO或BO也是可以接受的。
3，Service和DAO的接口之有无     
    接口是一种契约，可有多种实现。所以接口之有无取决于具体实现是否需要多样化。如果铁定一种DAO或一种Service只有一种实现，那么抽象出接口的意义不大。然而一些大型应用或许需要DAO和Service的多种实现（比如可能需要一种Hibernate实现、一种CMP实现和一种JDO实现），为了向上一层隐藏具体实现类，需要采用接口。    
    隐藏具体实现类的创建过程：一是实用工厂方法，代价是代码量大（每个DAO和Service一个工厂）。二是使用Spring的IoC，实现依赖注入，不需要写额外的代码。

    BO模型中业务逻辑的选择
    BO模型的业务逻辑可放在BO，也可放在Service层，如何切分?
    Rod Johnson提出原则是“case by case”，可重用度高的，和domain object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在Service层。
    robbin提出的原则是：看业务方法是否显式的依赖持久化。
    业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，就放在BO中。如脱离了具体持久化框架仍可进行单元测试。这样BO形成独立的，可移植的，完整的，自包含的域对象。