81,092
社区成员
发帖
与我相关
我的任务
分享业务逻辑放在控制层？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
我发觉公司的代码都是把业务逻辑放在action里实现的，然后service纯粹都是调dao就完了。
但是我觉得业务逻辑应该是放在service才对，然后action只管传参数进service，service返回数据。而且验证也应该放在service里，然后通过返回错误码之类的信息给action。大家觉得如何呢。。
但是我觉得业务逻辑应该是放在service才对，然后action只管传参数进service，service返回数据。而且验证也应该放在service里，然后通过返回错误码之类的信息给action。大家觉得如何呢。。
...全文
请发表友善的回复…
发表回复
土豆的老公 2015-01-07
- 打赏
- 举报
不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊[/quote]
如果事务拦截器切的是service层的话，service A调service B，B出错了A不会回滚的。
除非service里只调用dao，一个dao出错，所以的都会回滚。。[/quote]
为什么不在Action中调用一个service，然后将返回结果传入另外一个service中呢？不就达到了效果？我认为service不应该调用另外一个service，如果调用了，就相当于是一个service依赖于另外一个service，耦合性降低了。
飞客96004 2014-04-01
- 打赏
- 举报
不能回滚的事物 是什么意思呢？我还真没遇到过不能回滚的事务，能不能举例子讲一下啊[/quote]
如果事务拦截器切的是service层的话，service A调service B，B出错了A不会回滚的。
除非service里只调用dao，一个dao出错，所以的都会回滚。。[/quote]
哦，这样子啊。一般事务切 request就好了嘛，一次请求一个事务。
NickCheng 2014-03-04
- 打赏
- 举报
我们公司没有Dao层，只有Service层，业务逻辑当然也是放在Service去处理了，不过这只能是代码我们公司的习惯吧！
gggggame 2014-03-04
- 打赏
- 举报
service 好做事务回滚
时光是最好的解药 2014-03-03
- 打赏
- 举报
Dao层主要放实现代码、service层放业务方法、action对请求进行处理和转发。
如果不按逻辑出牌，代码随便放，说明代码规范还没到位
被妞追过的夏天 2014-03-03
- 打赏
- 举报
控制层不处理逻辑的，最好将代码放在service中，，
kky2010_110 2014-03-03
- 打赏
- 举报
其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？[/quote]
典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。[/quote]
看来版主的评论感觉很受启发，我在设计过程中确实很大部分是先写impl后写接口的，不知道版主有没有接口编程的博客能不能分享，版主有没有类似的推荐阅读的
kky2010_110 2014-03-03
- 打赏
- 举报
那参数是传什么？比如登陆的时候需要账号和密码，那service就2个string的参数？还是说公司封装了参数类和结果集类？因为一个service有可能被多个action或service调用，如果改了参数，那调用的地方都要跟着改。如果规定全部都传入指定的Params，并且全部返回Results，这样的话就不用每个地方都改了。。[/quote]
这个也简单啊
User user.name=name; user.password = pw;
service.判断是否有该用户(user) 返回false 或者true
houshen13828468384 2014-03-03
- 打赏
- 举报
全部放在action,说明习惯不好，呵呵
花谢尊前不敢香 2014-03-03
- 打赏
- 举报
这要看你代码结构的耦合度了，如果要完全解耦，那肯定要层次分明了。如果要求不太高，放在action里也是可以的。
ay转身遇 2014-03-03
- 打赏
- 举报
那参数是传什么？比如登陆的时候需要账号和密码，那service就2个string的参数？还是说公司封装了参数类和结果集类？因为一个service有可能被多个action或service调用，如果改了参数，那调用的地方都要跟着改。如果规定全部都传入指定的Params，并且全部返回Results，这样的话就不用每个地方都改了。。[/quote]
公司用的是自动代码生成，普通的增删改查都是自动生成的，登陆的时候service接收的是两个参数。不过有些地方有用到封装的参数，这个根据需要。
sca4441479 2014-03-03
- 打赏
- 举报
放纵的青春 2014-03-03
- 打赏
- 举报
一般不会直接写在action里面 稍微有点追求的都不想这样吧··
宁波朱超 2014-03-03
- 打赏
- 举报
公司怎么做你就怎么做 没有错
tony4geek 2014-03-03
- 打赏
- 举报
看 公司吧。很多公司规范都不一样，
csd6101 2014-03-03
- 打赏
- 举报
需求是要改的啦。。就比如一个service用来查某个报表的数据的，后来多加了几个参数，那调用这个service的地方都要加。。所以我是想要不要定义一个参数类，所有的service参数只能用一个Params，这样调用的地方就不用改了。。不知道这样好不好。[/quote]
传参数最好传对象吧，如果你预料到需求会变动比较多的话
不关橙猫猫事的哦 2014-03-02
- 打赏
- 举报
其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？[/quote]
典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。[/quote]
需求是要改的啦。。就比如一个service用来查某个报表的数据的，后来多加了几个参数，那调用这个service的地方都要加。。所以我是想要不要定义一个参数类，所有的service参数只能用一个Params，这样调用的地方就不用改了。。不知道这样好不好。
teemai 2014-03-02
- 打赏
- 举报
其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？[/quote]
典型的先写impl再写interface。
不知道你们架构师是咋整的。对于一个系统，要做的是先设计接口，而不是来了不同的方法（比如参数类型要求）才去写接口的。
如果需求定了，那么每一层的接口基本也就可以确定了。接口都确定了，就不存在所谓要该service的方法，因为都是确定的。
不关橙猫猫事的哦 2014-03-02
- 打赏
- 举报
其实我刚开始工作的时候也是这样，service纯粹就是调dao就完事了，业务逻辑完全是在action实现。后来理解了之后才发现这种写法不合适。。
我之前工作的那几家公司都是这样。现在换了一家也是这样。别人的代码是没法改了，我只能自己管好自己就是。。现在麻烦就在于service方法的参数，如果要新增参数的话，调service的地方都要全改，是不是你们公司有专门的参数类？
李保强 2014-03-02
- 打赏
- 举报
我觉得最好不要在action中放置业务逻辑。
service层就是专门做业务处理的，为什么要放在action中？那样service不就被架空了，没用了？
分层就是为了各司其职，也许每个公司有各自的习惯。但是如果不改变，那么这个公司怎么发展下去？
发现问题了，你可以跟自己的项目经理说，不管经理是不是采纳，至少你提了，说明你考虑这个问题了。
加载更多回复（10）
