啥时候用service啥时候用dao

技术框架: spring+ibatis
比如我有个文章详情页,页面右侧会显示“最火的10篇文章”,那么这10篇文章是从service里取还是从dao里取?我的习惯是直接从dao里取,service层留给业务概念里的“服务”。可是吧。。。如果是给传统企业做信息化,业务概念里倒是可能会看到“服务”,而我现在做的就是个网站(不管是新闻网站,博客还是别的什么),那么这个“服务”的概念从哪儿来呢?而且,现在技术部各组基本上都倾向于获取数据必须要经过service层。。。搞的我好纠结。。。。。。。。。

我的理解是在service的内部可以使用dao,在事件场景中也可以直接使用Dao,看你怎么用,好的话Dao也可以在仓储中,对Dao的调用也就是调用仓储

2012-12-17 10:42 "@lostalien"的内容
技术框架: spring+ibatis
比如我有个文章详情页,页面右侧会显示“最火的10篇文章”,那么这10篇文章是从service里取还是从dao里取?我的习惯是直接从dao里取,service层留给业务概念里的“服务”。可是吧。。。如 ...

是不是他们将权限之类的信息加在service层?什么东西都靠service来执行?DAO在我看来应该是可以处理所有的跟数据打交道的工具。

2012-12-19 11:04 "@snow0613"的内容
是不是他们将权限之类的信息加在service层? ...

没,我们没有把权限有关的放在service层。

回 zjsong2012 :
我们没有用什么事件,仓储之类的啦,就是普通的 spring+ibatis

我理解的Dao,如下:
Repository是对象的仓库,也就是保存对象的地方,一个真正的OO系统,业务层是围绕着活动的对象进行的,而这个活动的对象是从仓库中获取的,也是通过仓库进行对象的长久保管,也就是持久化——保存到数据库。
而DAO则没有如此OO的概念,DAO是Data access Object,DAO中有数据概念,还是没有摆脱数据库的影子。
所以,Repository替代DAO,是OO深入的趋势,但是在具体处理中,由于性能或设计不够周到或者一些事情把握不定,DAO还会存在一段时间,属于过渡式消失。
Repository和DAO两个概念比较中发现,Repository是相对对象而言,而DAO是相对数据库而言,只要我们还是使用关系数据库保存对象,也可能这两者都同时存在,因为侧重点不一样,但是可以肯定的是,业务层应该直接和Repository打交道,而不是DAO.