业务逻辑放在控制层？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？

Question

登录验证和一些过滤在action。其他逻辑全在service

Answer 1

每个公司都有自己的习惯，不能说哪种对错，关键看公司统一的风格；
不过业务放在service不好利用规则控制事务，当遇到需要回滚的事务和不能回滚的场景时，不好处理的

Answer 2

每个公司有每个公司的规范。但是理论上来说service层才是真正做业务逻辑这块的。

Answer 3

不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊
如果事务拦截器切的是service层的话，service A调service B，B出错了A不会回滚的。
除非service里只调用dao，一个dao出错，所以的都会回滚。。

Answer 4

我们公司是放在service层的，感觉比较好使！

Answer 5

那参数是传什么？比如登陆的时候需要账号和密码，那service就2个string的参数？还是说公司封装了参数类和结果集类？因为一个service有可能被多个action或service调用，如果改了参数，那调用的地方都要跟着改。如果规定全部都传入指定的Params，并且全部返回Results，这样的话就不用每个地方都改了。。

Answer 6

我觉得最好不要在action中放置业务逻辑。
service层就是专门做业务处理的，为什么要放在action中？那样service不就被架空了，没用了？分层就是为了各司其职，也许每个公司有各自的习惯。但是如果不改变，那么这个公司怎么发展下去？发现问题了，你可以跟自己的项目经理说，不管经理是不是采纳，至少你提了，说明你考虑这个问题了。

Answer 7

其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？

Answer 8

其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。

Answer 9

其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。
需求是要改的啦。。就比如一个service用来查某个报表的数据的，后来多加了几个参数，那调用这个service的地方都要加。。所以我是想要不要定义一个参数类，所有的service参数只能用一个Params，这样调用的地方就不用改了。。不知道这样好不好。

Answer 10

那参数是传什么？比如登陆的时候需要账号和密码，那service就2个string的参数？还是说公司封装了参数类和结果集类？因为一个service有可能被多个action或service调用，如果改了参数，那调用的地方都要跟着改。如果规定全部都传入指定的Params，并且全部返回Results，这样的话就不用每个地方都改了。。
公司用的是自动代码生成，普通的增删改查都是自动生成的，登陆的时候service接收的是两个参数。不过有些地方有用到封装的参数，这个根据需要。

Answer 11

这要看你代码结构的耦合度了，如果要完全解耦，那肯定要层次分明了。如果要求不太高，放在action里也是可以的。

Answer 12

全部放在action,说明习惯不好，呵呵

Answer 13

那参数是传什么？比如登陆的时候需要账号和密码，那service就2个string的参数？还是说公司封装了参数类和结果集类？因为一个service有可能被多个action或service调用，如果改了参数，那调用的地方都要跟着改。如果规定全部都传入指定的Params，并且全部返回Results，这样的话就不用每个地方都改了。。
这个也简单啊
User user.name=name; user.password = pw;
service.判断是否有该用户(user) 返回false 或者true

Answer 14

其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。
看来版主的评论感觉很受启发，我在设计过程中确实很大部分是先写impl后写接口的，不知道版主有没有接口编程的博客能不能分享，版主有没有类似的推荐阅读的

Answer 15

控制层不处理逻辑的，最好将代码放在service中，，

Answer 16

Dao层主要放实现代码、service层放业务方法、action对请求进行处理和转发。
如果不按逻辑出牌，代码随便放，说明代码规范还没到位

Answer 17

需求是要改的啦。。就比如一个service用来查某个报表的数据的，后来多加了几个参数，那调用这个service的地方都要加。。所以我是想要不要定义一个参数类，所有的service参数只能用一个Params，这样调用的地方就不用改了。。不知道这样好不好。传参数最好传对象吧，如果你预料到需求会变动比较多的话

Answer 18

一般不会直接写在action里面 稍微有点追求的都不想这样吧··

Answer 19

我们公司没有Dao层，只有Service层，业务逻辑当然也是放在Service去处理了，不过这只能是代码我们公司的习惯吧！

Answer 20

不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊
如果事务拦截器切的是service层的话，service A调service B，B出错了A不会回滚的。
除非service里只调用dao，一个dao出错，所以的都会回滚。。哦，这样子啊。一般事务切 request就好了嘛，一次请求一个事务。

Answer 21

不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊
如果事务拦截器切的是service层的话，service A调service B，B出错了A不会回滚的。
除非service里只调用dao，一个dao出错，所以的都会回滚。。为什么不在Action中调用一个service，然后将返回结果传入另外一个service中呢？不就达到了效果？我认为service不应该调用另外一个service，如果调用了，就相当于是一个service依赖于另外一个service，耦合性降低了。