业务逻辑应该放在sql里面吗?以及事务到底该怎么用?
发布于 2 个月前 作者 Shonke 752 次浏览 来自 问答

一个请求,肯定会有查N次查询,进行各种判断逻辑,逻辑应该放在哪里做? A.使用存储过程直接干 B.简单的能用orm用orm,不能的手写查询,然后转化成model实例 B.完全不用/少用join,按照条件查出来本地处理 C.先查相关记录的id,然后用orm去取。根据需要加meta表,计算逻辑全在meta表里面,也方便加orm的缓存 D.不用orm,纯手工

然后就是事务在实际场景到底怎么用 需要操作多个service层的时候很可能就用到事务,在写的时候是该把事务一层层传下去吗,还是不用事务?或者使用cls-hooked这种东西? 还有如果用事务的话,里面可能有一些逻辑,然后比较耗时,然后长期占用了连接池,导致后面的请求处理不了

9 回复

新入后端,希望有人能够帮忙解答一下么,谢谢了

@Shonke java的话,现在是查询能ORM出来的就ORM,然后处理字段还是用query加上DTO的方式,当然如果考虑ORM性能优化,那又不一样了,一般ORM会提供一些方法之类的东西来处理逻辑的,比如data-JPA的话,就是你写一个接口叫findUserById,你直接调用这个接口,它会帮你处理逻辑,业务逻辑方面的话,我觉得所谓的业务逻辑是指JSON格式的转换、参数处理这种把,一般是把参数处理成我们想要的,然后调用方法去查询,这些在查询数据后,在Service进行转换的操作,本来Entity和DAO结合就是用来查询数据的,然后在Service转换。整个流程在不同语言都是类似的。

至于多service事务的问题,我还没接触过,坐等大佬们起床 :|)

@869288142 orm提供的其实只有一些简单的过滤条件。 业务逻辑不只是格式的转换、参数处理啊,这里边也可能和数据库互交多次。

有个问题,如果是想要在entity实例附带一些数据,是怎么写的 比如说,有一个订单列表,每条记录都会附加一些状态信息。然后需要调用其他sevice获得,这里是该传id还是entity实例进去? 以及返回的一些状态信息,需要附加到每条订单里边,这个时候应该先序列化每条订单记录,然后加进去?

可能我表述有点不太清楚,见谅哈

好冷清啊

干掉存储过程 干掉外键检查 保留简单 join 逻辑应用里控制 以上都是为了数据库性能,因为数据库资源总比应用资源昂贵

C 可以试试没用过, ORM 有比没有好, 两个 service 组成一个事务没研究过

看看优秀项目代码是怎么做的

@wiviwiv 干掉外键检查真的没有关系吗?我们现在的做法是D,也确实存在一些问题。

@gyj1278 干掉外键其实还好,有人嫌耗性能 外键是挺烦的,话说上次碰到外键的一个坑,在事务里面更新了某个表的一列,导致外键引用了这个列的记录都被锁了,当然这也是我不够了解的问题 好像一般做法是,测试环境用外键,测完上线就删掉

纯手工写sql也是厉害了

@wiviwiv 那么,能介绍个比较好吃的项目吗?

@Shonke 我们就是封装了一下mysql,然后sql语句就是纯拼写,我听说阿里禁用join,我们的项目里面动手就是join。

回到顶部