关于spring+struts+hibernate中的service层是否必须的问题？

Question

service 一般没必要，除非你的程序要处理钱之类的东西。

Answer 1

Service层是实际的业务逻辑层。不管怎么说一个应用总有自己的业务，如果没有业务那就没必要做这个应用了。当然了不要Service层，那就势必将一些业务（比如购物网站的，积分计算，结账计算等）揉道控制层或是持久层中去了。增加了另外2个层的冗余代码，如果你的业务不复杂的话，可以拆，如果业务复杂的还是老老实实弄个Service层吧

Answer 2

有service层的话感觉有个问题，就是事务的问题。假如我要添加一个人员的同时，添加一个新部门到库中，那么直接在DAO层写的话放在一个事务中进行两个添加操作没什么问题，假如我要放在service层中的话要分别调用人员管理的DAO，部门管理的DAO，两个DAO的添加操作在不同的事务中。而如果把这个同时添加人员部门的逻辑写道DAO中的话那么相当于把逻辑写到了DAO层中，那么这个service层就没意义了

Answer 3

jspren(人民老百姓)说的不太对吧。如果把事务处理交给SPRING的话，在一个service里调用两个DAO，其实是在同一个事务里的。如果某个DAO抛出异常的话，SPRING会来控制回滚的。如果不用service，不用SPRING来控制事务，那还用SPRING干什么。
刚学SPRING，了解也不是很多。还请指教

Answer 4

在service中调用两个DAO,肯定不是在一个事务中阿

Answer 5

spring就是用了个注入功能阿,还有个代理

Answer 6

对于依赖容器的参数化事务管理而言，Spring 则表现出了极大的价值。Spring
本身也是一个容器，只是相对EJB容器而言，Spring显得更为轻便小巧。我们无需付
出其他方面的代价，即可通过Spring实现基于容器的事务管理（本质上来讲，Spring
的事务管理是基于动态AOP）。
摘自《Spring 开发南》在service中调用两个DAO,肯定不是在一个事务中阿，你测试过吗？配置对了吗？
配置没问题的话两个DAO是在一个事务里的。

Answer 7

严重批判 jspren(人民老百姓) ！！！！  你说的没道理！建议事务处理在service层！
-------------------------------------------------------------------
有service层的话感觉有个问题，就是事务的问题。假如我要添加一个人员的同时，添加一个新部门到库中，那么直接在DAO层写的话放在一个事务中进行两个添加操作没什么问题，假如我要放在service层中的话要分别调用人员管理的DAO，部门管理的DAO，两个DAO的添加操作在不同的事务中。而如果把这个同时添加人员部门的逻辑写道DAO中的话那么相当于把逻辑写到了DAO层中，那么这个service层就没意义了
-------------------------------------------------

Answer 8

单从实现的角度看任何框架多是没有用的（所有的显示和业务处理都放在jsp中），之所以要分层实现是站在设计的角度看，从经常改变的东东中抽象出不变的东东（interface），这样对象之间的依赖就减弱了

Answer 9

所以我还是不要service层了

Answer 10

EQsay()果然是高手,说到本质问题,做WEB为什么要分层?为什么要MVC?其实本质原因是相同的,就是delegate和decouple。其实所有的工作完全可以都在JSP中完成，为什么要有新的层出现？我认为是为了增加应用的灵活性和扩展性还有健壮性等等问题，说的实际一点，就是，如果把所有的工作都在JSP,那么有一天我们要换个数据库怎么办?如果中间一个环节坏掉了又怎么办?这些都是灵活性以及扩展和健壮的表现.在原有的结构上出了问题我们才会抽象出新的层次结构来解决.当然分层的原因和理由远不止这些,在现在的WEB应用中还有更多的体现,比如SOA等等很多,能写一大篇文章,究其根本其实都是为了实现JAVA本身在结构上灵活,复用等等的特点,也实现了OO的思想.如果从这个方向上看这个问题,那么DAO层为了持久化,SERVICE层是实现系统能够提供的服务(我认为服务的概念很重要).而ACTION层是用一些服务(注意,这里可能是本系统的服务,也可能是其他系统的服务)来完成特定的动作.每一个层次的任务都是不同的,这是delegate的一部分.当然,如果你把SERVICE和Action层合并,在小的系统中没有问题,但它决不是良构的.
说的有点多,这是我对分层的一些看法,和大家讨论一下,不同的系统因情况不同而论应该采用不同的结构,也不能一概而论哪个就是好,哪个就是不好,只有对于某一个项目而言更加适合的问题.
对于前面说的事务问题,在Sping中进行配置,可以控制事务的范围,在一个DAO或者多个DAO中实现事务管理都是可以的.

Answer 11

我手下正在做一个小模块，我的包划分是这样的：com.mycompanyname.mymodulename.dao
com.mycompanyname.mymodulename.dao.impl
com.mycompanyname.mymodulename.model
com.mycompanyname.mymodulename.service
com.mycompanyname.mymodulename.service.impl
com.mycompanyname.mymodulename.webmodel里面放的是MVC中的M
web包里面放一些servlet类，当然你也可以放一些struts的Action类
service里放的是业务层组件，其下的impl包则是实现类
dao里面放和数据库操作有关的接口，其下的impl包则是实现类因我正在开发的模块的业务流程比较复杂，所以，为了以下二个目的，特地划分出了业务层：
1、业务组件代码重用：表现层有多个servlet需要用到同一个业务层组件；
2、让表现层更清晰：表现层的servlet只应该关注于流程的控制，如果把复杂的业务层代码混入表现层，那么必将导致表现层代码凌乱，导致后期的其它开发人员难以维护。
3、将来升级的需要：在将来可以给表现层加上权限控制，给业务层组件加上事务。我认为，只要业务不是很复杂，可以省略掉业务层，直接在MVC的C中调用DAO层代码，但是为了将来的维护等问题，还是建议单独建一层业务层。