一个入门级的问题，希望大家给与解答 最近在做一个项目，刚入手，发现DAO层与Service层的代码几乎是一模一样。目前对各个层之间的关系还不是很明白，尤其是service层——业务逻辑层。不知道这层是用来做什么的，而现在又碰到DAO层与service层代码相似的问题，觉得有点头大。。求帮助，求赐教。。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 service中主要是写一些业务逻辑的，dao层主要是与数据库打交道的 service层和dao层怎么可能是一模一样呢，service层是处理业务逻辑的，dao层是可以说直接进行数据库操作的，mvc三层的出现就是为了解决逻辑分明，代码清晰用的，这是很好的框架，多学学就理解了 每个层的功能我是知道的，但是实现起来还是有点困难的，所以我借鉴了公司里面的其他项目 ，发现 DAO 接口 和 Service接口 在代码上 十分的相似所以我才有疑问的 通俗地讲,数据从DAO出来之后如果需要处理,那就是在SERVICE处理,比如数据库里是数字,但是页面上是汉字表示,那么这个转换过程就是在SERVICE完成的,不知道这么讲算不算科学,希望能帮到楼主 你好 楼主 我刚工作 一个月 和你有相似的经历 但是经过一个月的工作Service 是调用 Dao ，Dao 主要是和数据库打交道，一般负责增删改查。可能你是刚进公司 所以 你会感觉Dao 和 Serviec有些 相似 ，当你有经验时 ，你会发现 Service 将 Dao层中的数据 进行加工 得到 我们想要的 业务~ 个人理解，dao只负责单纯的数据库操作，并不参与具体的业务逻辑，service才负责具体的业务逻辑，DAO层与service层代码相似应该是项目的业务逻辑也有很多单纯的增删查改操作而已 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层的方法，加上一些逻辑内容。 楼主的项目比较小 所以看不出service和dao层的很大区别当实际项目具有一定的规模的时候就可以体现service层在业务逻辑上的逻辑体现了 dao 只负责 增删改查、其他的事情逻辑别往这里写、（尤其是项目赶工快完成的时候）service只负责逻辑处理、加工一下数据、他们倆的关系就类似 原材料（DAO）---》加工厂(SERVICE) 问一点BPEL的一些相关的东西 100 求问?????????? hibernate模糊查询出错！！ 询问一个hibernateTemplate的简单问题 javamail发送和接收邮件的身份验证问题。。给100分，急！ 有没有一个OR Mapping自动生成类的工具，不要整套的解决方案，只要一个自动类生成的工具。 JTable中的数据显示问题，请各位帮忙，小女子在此谢谢各位ggjj了 float 型如何转化为 String MyEclipse Building workspace 笔试遇到的问题 struts+spring+ibatis框架搭建 请教个关于struts2用ajax的问题
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进行数据传递。显然后者实现更理想，但是你不觉得这样很麻烦吗。
简单的说dao层就是数据库的一些操作，逻辑设计很少，而service就是调用dao层的方法，加上一些逻辑内容。
当实际项目具有一定的规模的时候就可以体现service层在业务逻辑上的逻辑体现了
其他的事情逻辑别往这里写、（尤其是项目赶工快完成的时候）service只负责逻辑处理、加工一下数据、
他们倆的关系就类似 原材料（DAO）---》加工厂(SERVICE)