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形成独立的,可移植的,完整的,自包含的域对象。
DAO和Service层
最新推荐文章于 2023-02-14 00:48:01 发布