日期:2014-05-19  浏览次数:20610 次

一个入门级的问题,希望大家给与解答
最近在做一个项目,刚入手,发现DAO层与Service层的代码几乎是一模一样。
目前对各个层之间的关系还不是很明白,尤其是service层——业务逻辑层。不知道这层是用来做什么的,而现在又碰到DAO层与service层代码相似的问题,觉得有点头大。。求帮助,求赐教。。

------解决方案--------------------
service中主要是写一些业务逻辑的,dao层主要是与数据库打交道的
------解决方案--------------------
dao完成连接数据库修改删除添加等的实现细节,例如sql语句是怎么写的,怎么把对象放入数据库的service层是面向功能的,一个个功能模块比如说银行登记并完成一次存款,UI要把请求给service层,然后service曾将这一个case分解成许多步骤调用底层的实现完成这次存款,dao就是下面那层。 
dao就是把数据存起来,之所以service的方法会有雷同只不过是因为service得需求不是很复杂不用再service里面完成太多包装或者处理过程可以直接调用dao的方法就完成的请求处理例如就要save一个对象,而这个对象是封装好的,dao里面有个方法专门save封装好的对象于是service的方法就仅仅调用一下就o了,函数签名自然很像了service不能直接接触持久层,而dao是持久层或者直接访问持久层有的时候只是为了分层清楚,为了将来scale up的时候方便我们才把service和dao分开,其实没必要分开的。 

--------------------------- 
根据不同项目的复杂度来确定是否需要分层,如果是小项目的话,2层应该就够了,分层是为了很好的解耦,和程序的可观性,还有就是很好的项目分工,如果遇到某个客户需要修改某个查询结果集合,你需要修改的首先是dao的SQL,接着是service的相应调用方法来为VIEW服务, 
如果是分层清楚的话,只需要在DAO中加一个方法,在SERVICE中改变起调用的方法街口,需要改动的不大, 

----------------------------- 
在用ssh进行开发中,一般情况下都是分为三层:web层spring层dao层,基本的流程是首先定义一个dao接口,然后去实现这个接口,在定义同类型的service接口(service接口与dao接口是完全一样),再实现service接口,(这是是用dao接口去注入),然后web层在去调用service层。 
DAO层的职责是纯粹的数据操作, 如果是hibernate, 那就只需要类似getHibernateTemplate().save, update, delete, findyBy*这类的方法而service层是负责写业务逻辑的, 纯粹的业务逻辑, 其中的数据操作是通过注入的DAO实现的, 但是业务是在这层。 
如果你的service层与dao层代码严重重复,这说明你的业务比较简单。复杂业务这个结构的优势就很明显了service层的作用是对dao取得的数据做操作 更贴近于业务的实现 dao只是数据的增删改查,对小型的应用来说,SSH 确实提高了开发成本和开发周期,但是却有利于扩展和维护。 
利用spring 的ioc 解偶 使业务逻辑与持久层松偶合。 

----------------------------- 
分层并不一定是绝对的,具体的还是要根据项目实际情况来定,不是么?如果是理想状态的话,恐怕在你的service层上面还要再多加一层的。但是你觉得有必要吗? 

实际上,对于小项目来说,直接通过dao来进行操作也不是不可以,搞得太复杂,也没有必要。这是我的个人感觉。就好像po和dto一样,有的人直接就将po传到web层,有的还要加一个转换,由dto进行数据传递。显然后者实现更理想,但是你不觉得这样很麻烦吗。
------解决方案--------------------
有些表我们可能就做增删改查的操作的时候,你会看到你的service层和dao层的接口很接近的,可能都是增删改查4个方法。但是在实现上可能就不一样了,比如说在添加的方法中,可能在service可能要处理传过来的数据并组装成对象然后再把对象当做参数传递到dao层,而dao层可能就对数据库进行操作。而有些表可能会涉及到很多复杂的操作,这样在service层可能就会有很多dao层没有的接口了。比如用户的登录,可能在service层会有这个接口,但是到dao层就没有。service就是调用几个dao层的方法组合并加上自己的一些逻辑判断了。
简单的说dao层就是数据库的一些操作,逻辑设计很少,而service就是调用dao层的方法,加上一些逻辑内容。