这是一个创建于 3224 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天工作时做一个对外的 ejb 接口，我把业务逻辑放在 service 层，然后别人告诉我别这样写，要写在 plsql 里，写一个存储过程里面写业务逻辑.是这样吗？ Action ， Service ， DAO 这三层之所以划分，不就是为了解耦业务逻辑， action 只负责分发 service ， service 负责逻辑， dao 负责处理传过来的数据然后取数据。
把业务逻辑写在 plsql 有更好吗？？是我的理解有问题吗？
 |
1
asj 2016-01-28 05:41:50 +08:00 via Android
目测这个别人超过 40 岁了
|
 |
3
jsrgqinbin 2016-01-28 08:58:28 +08:00
是不是电信类项目里出来的？
|
 |
4
ArthurKing 2016-01-28 09:21:46 +08:00
根据实际情况决定吧。现在的项目要处理大量数据，也会生成大量数据。业务逻辑中的数据处理部分放在存储过程里，数据只在数据库层面流动，减少了很多数据库与应用间的数据交换。而且运维方便，也方便数据库开发人员查找问题。
|
 |
5
weizhiyao008 2016-01-28 09:55:00 +08:00
我也很喜欢把业务放到存储过程里面，但是也得分情况啊，并不是所有的都必须放到存储过程里面的，需要大量计算的，我就不放到存储过程里面
|
 |
6
xiamingchong 2016-01-28 10:02:21 +08:00
别听他的
|
 |
7
chengcanmm77 2016-01-28 10:31:10 +08:00
这要是访问量大的话，数据库不会挂调？。。。
|
 |
8
domty 2016-01-28 11:37:07 +08:00
看别人的代码是怎么写的
一般来说他告诉你这么写就是说这么写可能就是项目的开发标准 项目代码最忌讳一个人一个风格 你把业务写 service 他把业务写成存储过程 维护和修改起来是很麻烦的 |
 |
9
heian0224 OP @chengcanmm77 访问量不会大，而且数据库挂掉也就是加钱加机器的事。
@ArthurKing 减少数据库与应用交互这个可以理解，但这样做不符合分层的意义了，我直接取 dao 不就可以了，反正业务逻辑在 sql 中 |
|
10
ArthurKing 2016-01-28 13:55:47 +08:00
@heian0224 根据项目实际情况来吧。不能死板的迎合分层的理念而去分层。在一些大数据量、业务逻辑复杂，且测试环境很难去模拟生产环境的项目中，你会发现把业务逻辑写在存储过程里还是很有必要的。
|
 |
11
wupher 2016-01-28 14:20:14 +08:00  1
之前在做运营商系统中见过这种做法的。
个人不喜欢这样，还是喜欢在 Java 代码中放入业务逻辑。好测试（ TestCase ），易于重构与复用，也方便并发计算，换数据库（这事很少见，但是也碰到过）不至于当场晕倒。 这种做法，虽然不认同，但是也能理解。有错误或者业务调整易于修复或改写；不需要重新部署。 比较中立一点得说，看个人喜好了。确实有的同事对于 Java 语言实在无爱，就喜欢搞 Oracle ，啥都写存储过程的。 |
|
12
heian0224 OP @ArthurKing 业务逻辑复杂写在存储过程可以理解，比如说一些跑批。但是有些业务就是查一点数据，两个 select 的事，就是迎合别的系统做的东西，基本不会公用，那我何必又放在存储过程？
|
|
13
ArthurKing 2016-01-28 15:07:28 +08:00
@heian0224 强调了两次，按项目实际情况来。一般项目都可以逻辑放 service ， dao 执行的只是简单的增删改查。但是有些项目就得根据实际情况选择适合的方式，而不是死板套模式
|
Select Language