发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 3 4 ... 7 下一页 Go 7

层的职责的请教

                   
2006-06-24 17:07
赞助商链接

现在后台分成如下几个层:
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
2006-06-26 12:50

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

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

2006-06-26 15:49

ok
那你的意思是
service的方法 >= dao的方法?
这样会不会存在我上面说的繁琐呢

2006-06-26 18:48

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

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

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

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


2006-06-27 09:32

明白了
所以现在对于这个方法在dao中定义还是在service中定义
问题都不大
好比那个方法,可以在daoimpl中直接操作sql来实现
也可以在service中通过缓存什么的来实现
并不重要

关键在于,service的存在,是为系统扩展留下的后路?
是不是这个意思?

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

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com