一个请求，肯定会有查N次查询，进行各种判断逻辑，逻辑应该放在哪里做？ A.使用存储过程直接干 B.简单的能用orm用orm，不能的手写查询，然后转化成model实例 B.完全不用/少用join，按照条件查出来本地处理 C.先查相关记录的id，然后用orm去取。根据需要加meta表，计算逻辑全在meta表里面，也方便加orm的缓存 D.不用orm，纯手工
然后就是事务在实际场景到底怎么用 需要操作多个service层的时候很可能就用到事务，在写的时候是该把事务一层层传下去吗，还是不用事务？或者使用cls-hooked这种东西？ 还有如果用事务的话，里面可能有一些逻辑，然后比较耗时，然后长期占用了连接池，导致后面的请求处理不了
@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 组成一个事务没研究过
看看优秀项目代码是怎么做的
@gyj1278 干掉外键其实还好，有人嫌耗性能 外键是挺烦的，话说上次碰到外键的一个坑，在事务里面更新了某个表的一列，导致外键引用了这个列的记录都被锁了，当然这也是我不够了解的问题 好像一般做法是，测试环境用外键，测完上线就删掉
纯手工写sql也是厉害了