层的职责的请教

06-06-24 pushboy
                   

现在后台分成如下几个层:

Domain:提供getter/setter

Dao:接口,定义了持久化方法,CRUD

DaoImpl:Dao的实现

Service:业务逻辑

但是在实际的过程中发现,service里面有很多涉及到持久化的查询、更新操作,那么,这些方法是在dao中定义呢?还是在service中定义和实现?

比如,对于一个 客户资料UserOrder 实体

dao中定义了getUserOrderByID() getAllUserOrder() insertUserOrder() updateUserOrder() delUserOrder()五个方法

现在需要一个 根据地区查询客户getUserByArea(),或者 根据产品线和地区查询客户 getUserByAreaSrv()

这样的方法,定义在service还是dao中?

第二个问题。service层肯定是面向客户端调用的,那么dao层对于客户端是否暴露?

就是说,service层中是否提供dao中的方法,比如getAllUserOrder() insertUserOrder()这些方法?

如果不提供,那么客户端需要知道哪些是dao中提供的,哪些是service提供的

如果提供这些方法,意味着所有的方法需要在dao中定义,daoimpl中实现,service中包装,是否太重复和烦琐?

多谢

                   

1
asklxf
2006-06-26 12:50

DAO只负责数据库操作,不涉及任何逻辑

Service就需要业务逻辑了,比如getUserOrder()在DAO,你就查数据库就行,在service中,你可能需要首先验证当前用户是否有这个操作权限,然后调用DAO,最后记录日志

pushboy
2006-06-26 15:49

ok

那你的意思是

service的方法 >= dao的方法?

这样会不会存在我上面说的繁琐呢

banq
2006-06-26 18:48

>需要在dao中定义,daoimpl中实现,service中包装,是否太重复和烦琐?

其实这不会发生,因为你认为getUserByAreaSrv()方法肯定一定要完全从数据库完成,其实不然,其实我可能只从数据库查询一个ID集合,然后,在服务层再通过缓存访问封装成完整的Model。这些都需要在Service完成(只是一个比喻)。

预留Service是为防止你的业务系统复杂化之后有一个插脚的地方。

现在很多系统就没有这种插脚的地方,在struts的Action中直接调用Hibernate数据库操作,如那个日本人做的开发框架RoR就是这样,这些以丧失可维护性做代价的快速开发都是伪框架。

所以,为你的系统将来留着Service。

pushboy
2006-06-27 09:32

明白了

所以现在对于这个方法在dao中定义还是在service中定义

问题都不大

好比那个方法,可以在daoimpl中直接操作sql来实现

也可以在service中通过缓存什么的来实现

并不重要

关键在于,service的存在,是为系统扩展留下的后路?

是不是这个意思?

7Go 1 2 3 4 ... 7 下一页