业务逻辑该放在哪？

[heian0224]

今天工作时做一个对外的 ejb 接口，我把业务逻辑放在 service 层，然后别人告诉我别这样写，要写在 plsql 里，写一个存储过程里面写业务逻辑.是这样吗？ Action ， Service ， DAO 这三层之所以划分，不就是为了解耦业务逻辑， action 只负责分发 service ， service 负责逻辑， dao 负责处理传过来的数据然后取数据。
把业务逻辑写在 plsql 有更好吗？？是我的理解有问题吗？

[asj]

目测这个别人超过 40 岁了

[heian0224]

@asj 可惜猜错了，这个别人就比我大几岁

[jsrgqinbin]

是不是电信类项目里出来的？

[ArthurKing]

根据实际情况决定吧。现在的项目要处理大量数据，也会生成大量数据。业务逻辑中的数据处理部分放在存储过程里，数据只在数据库层面流动，减少了很多数据库与应用间的数据交换。而且运维方便，也方便数据库开发人员查找问题。

[weizhiyao008]

我也很喜欢把业务放到存储过程里面，但是也得分情况啊，并不是所有的都必须放到存储过程里面的，需要大量计算的，我就不放到存储过程里面

[xiamingchong]

别听他的

[chengcanmm77]

这要是访问量大的话，数据库不会挂调？。。。

[domty]

看别人的代码是怎么写的
一般来说他告诉你这么写就是说这么写可能就是项目的开发标准

项目代码最忌讳一个人一个风格 你把业务写 service 他把业务写成存储过程 维护和修改起来是很麻烦的

[heian0224]

@chengcanmm77 访问量不会大，而且数据库挂掉也就是加钱加机器的事。

@ArthurKing 减少数据库与应用交互这个可以理解，但这样做不符合分层的意义了，我直接取 dao 不就可以了，反正业务逻辑在 sql 中

[ArthurKing]

@heian0224 根据项目实际情况来吧。不能死板的迎合分层的理念而去分层。在一些大数据量、业务逻辑复杂，且测试环境很难去模拟生产环境的项目中，你会发现把业务逻辑写在存储过程里还是很有必要的。

[wupher]

之前在做运营商系统中见过这种做法的。
个人不喜欢这样，还是喜欢在 Java 代码中放入业务逻辑。好测试（ TestCase ），易于重构与复用，也方便并发计算，换数据库（这事很少见，但是也碰到过）不至于当场晕倒。

这种做法，虽然不认同，但是也能理解。有错误或者业务调整易于修复或改写；不需要重新部署。

比较中立一点得说，看个人喜好了。确实有的同事对于 Java 语言实在无爱，就喜欢搞 Oracle ，啥都写存储过程的。

[heian0224]

@ArthurKing 业务逻辑复杂写在存储过程可以理解，比如说一些跑批。但是有些业务就是查一点数据，两个 select 的事，就是迎合别的系统做的东西，基本不会公用，那我何必又放在存储过程？

[ArthurKing]

@heian0224 强调了两次，按项目实际情况来。一般项目都可以逻辑放 service ， dao 执行的只是简单的增删改查。但是有些项目就得根据实际情况选择适合的方式，而不是死板套模式