业务逻辑放在控制层？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
我发觉公司的代码都是把业务逻辑放在action里实现的，然后service纯粹都是调dao就完了。
但是我觉得业务逻辑应该是放在service才对，然后action只管传参数进service，service返回数据。而且验证也应该放在service里，然后通过返回错误码之类的信息给action。大家觉得如何呢。。
------解决方案--------------------
登录验证和一些过滤在action。其他逻辑全在service
------解决方案--------------------
每个公司都有自己的习惯，不能说哪种对错，关键看公司统一的风格；
不过业务放在service不好利用规则控制事务，当遇到需要回滚的事务和不能回滚的场景时，不好处理的
------解决方案--------------------
看各自公司的习惯吧！
------解决方案--------------------
嗯，这的确得看公司的习惯...
------解决方案--------------------
每个公司有每个公司的规范。

但是理论上来说service层才是真正做业务逻辑这块的。
------解决方案--------------------
存在即合理。
再说了，人在屋檐下，等你有了话语权再向公司质疑这些也不迟。
------解决方案--------------------

引用:

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

不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊
------解决方案--------------------
我们公司是放在service层的，感觉比较好使！
------解决方案--------------------
我觉得最好不要在action中放置业务逻辑。
service层就是专门做业务处理的，为什么要放在action中？那样service不就被架空了，没用了？

分层就是为了各司其职，也许每个公司有各自的习惯。但是如果不改变，那么这个公司怎么发展下去？

发现问题了，你可以跟自己的项目经理说，不管经理是不是采纳，至少你提了，说明你考虑这个问题了。
------解决方案--------------------

引用:

Quote: 引用:

我觉得最好不要在action中放置业务逻辑。
service层就是专门做业务处理的，为什么要放在action中？那样service不就被架空了，没用了？

分层就是为了各司其职，也许每个公司有各自的习惯。但是如果不改变，那么这个公司怎么发展下去？

发现问题了，你可以跟自己的项目经理说，不管经理是不是采纳，至少你提了，说明你考虑这个问题了。

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

典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。
------解决方案--------------------

引用:

Quote: 引用:

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

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

公司用的是自动代码生成，普通的增删改查都是自动生成的，登陆的时候service接收的是两个参数。不过有些地方有用到封装的参数，这个根据需要。
------解决方案--------------------
这要看你代码结构的耦合度了，如果要完全解耦，那肯定要层次分明了。如果要求不太高，放在action里也是可以的。
------解决方案--------------------
全部放在action,说明习惯不好，呵呵
------解决方案--------------------

引用:

Quote: 引用:

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

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

这个也简单啊
User user.name=name; user.password = pw;
service.判断是否有该用户(user) 返回false 或者true
------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用: