Service层的上面，是不是还应该有一层处理逻辑的东西？

[abcbuzhiming]

实践中，用spring管理的ssh架构都是action——service——Dao——数据库这样的层次结构，一般来说，事务控制都编织在service层上。并且大部分文章都说service是用来处理业务逻辑的。但是实际实践中，我觉得，似乎service层并不能涵盖所有的业务逻辑。比如下面这个场景。服务器有一个自动注册功能，客户发送请求，由服务器随机生成账号并插入数据库，因为同时可能有多个请求，造成随机用户名撞车的现象，因此用于注册的service层是可能抛异常的，而我们知道service层内部是不应该捕获异常的否则会影响到事务回滚，那么try catch这部分代价就会放到service层之外，也就是action层中，在action层中生成随机用户名，调用service插入数据库，如果插入失败（异常），则生成新的随机用户名继续尝试插入，直到成功。但是这样，等于一部分逻辑代码移动到了action中，这是合理的吗？action不应该是纯表现层吗？有时候客户端发来的请求是不涉及数据库的，但是要涉及到服务器计算，这些放在service我觉得就不是很合适啊，是不是说action和service之间还应该有一层呢，请教各位？

[剑神一笑]

分层不是说action就一点数据处理都没有，只要保证业务处理按照需求来走，该回滚回滚，灵活处理 分那么多层干什么，我觉得dao层都可以不要，只要能保证事物，直接在service里面做数据持久化都可以， dao只是让代码更好看而已

[abcbuzhiming]

引用 3 楼 hanpoyangtitan 的回复:

你理解有误吧？service 不能吞掉异常，不是service层不能捕获异常，service层可以捕获逻辑性的异常，可以处理或者转抛一个或者新建一个异常抛给action处理。 生成账号的逻辑不能放在 action，也不能放在service，应该由数据库procedure，function处理，应用是可以做集群的，做了集群你那个创建账号的逻辑会狂报错，冲突冲突，访问量大情况会够你呛。

我一直都在困惑到底该不该用数据库procedure，我有个同学在京东，他说他们几乎从来不用procedure，京东的服务器也是集群

[什么都不能]

引用 4 楼 abcbuzhiming 的回复:

[quote=引用 3 楼 hanpoyangtitan 的回复:] 你理解有误吧？service 不能吞掉异常，不是service层不能捕获异常，service层可以捕获逻辑性的异常，可以处理或者转抛一个或者新建一个异常抛给action处理。 生成账号的逻辑不能放在 action，也不能放在service，应该由数据库procedure，function处理，应用是可以做集群的，做了集群你那个创建账号的逻辑会狂报错，冲突冲突，访问量大情况会够你呛。

我一直都在困惑到底该不该用数据库procedure，我有个同学在京东，他说他们几乎从来不用procedure，京东的服务器也是集群[/quote] 不用有不用的处理方法，但你这个生成注册码的逻辑要检查下了。京东的系统有好多，你的同学接触也就一部分，还有可能是一个系统的一部分，怎么就能说京东的系统几乎不写procedure? 如果你的同学是京东的高级架构师，那我就完全信服了。否则的话，数据挖掘那块能没有数据库的过程？

[loveunittesting]

action是处理界面相关的逻辑，比如界面跳转逻辑，回传参数的逻辑，还有调用不同服务层方法的逻辑。

[什么都不能]

你理解有误吧？service 不能吞掉异常，不是service层不能捕获异常，service层可以捕获逻辑性的异常，可以处理或者转抛一个或者新建一个异常抛给action处理。 生成账号的逻辑不能放在 action，也不能放在service，应该由数据库procedure，function处理，应用是可以做集群的，做了集群你那个创建账号的逻辑会狂报错，冲突冲突，访问量大情况会够你呛。