一个 service 引用几十个 dao 如何优化？

[smeraldo]

假设一个场景：删除用户，需要同时删除所有相关的用户数据，那 DeleteService 除了引用很多很多 dao 以外有没有更好的做法？

[Raymon111111]

异步的做

[smeraldo]

发现不能编辑主题。。
不是性能的问题，是 DeleteService 的依赖太多了，感觉是 code smell

[wfd0807]

已经到 Dao 层面了，就不是 code smell 这么简单了
是不是 DB 层面用户数据结构过度设计？是不是业务过于集中？
总之，仅仅针对 DeleteService 无法彻底优化，顶多封装 component，隐藏 dao 的依赖(眼不见心不烦)

[lovedebug]

删除用户是比较少见的操作，我这一般都是一个 db procedure

[jingxyy]

使用消息队列解耦，删除用户生成一条消息扔到队列里，各相关系统订阅该事件完成各自逻辑，各相关系统控制各自对象的生命周期。

[lihongjie0209]

观察者模式， 依赖一个 list<Ob>

interface Ob{

void onUserDelete(long userId);


}

[lsongiu]

消息队列+1

[jorneyr]

例如 MyBatis 里可以一次执行多条 SQL 语句

[lihongjie0209]

至于如何注册所有的观察者到 DeleteServer 也很简单， 初始化的时候通过"ioc.getByType(Ob.class)" 手动初始化，只要是 iocbean 之内的对象都可以自动注册到 DeleteService


关于消息队列， 我的意见的如果只是为了解耦， 还是不要用的好， 不然你 debug 的时候就很难受了， 一个简单的系统没必要上这么重的组件

[leon0903]

@smeraldo 没出现性能问题 我觉得不用去管他。。。。。

[NoKey]

现在还有这么实诚的删除用户数据？
凡事要删除的，在某张表里标记一个删除
正常手段查不到这个数据而已

[ppwangs]

存储过程

[leeg810312]

只有欧盟数据保护法要求用户申请删除时必须真删数据，其他情况不都是软删除吗？

[smeraldo]

@NoKey
@leeg810312
假设的场景, 不过就算是逻辑删除, 那也得操作几十张表啊😂

[NoKey]

@smeraldo 看具体实现，一般来说，我接触的，信息有消息通过一张表来体现，只要这张表表明信息无效，连带的其他表都不用查了

[reeco]

事件驱动去解耦

[gejun123456]

没啥问题，没必要优化

[Allianzcortex]

我也觉得 @NoKey 的做法好，判断的时候加一个 isActivate 就好

@jingxyy 感觉好像会更复杂...Web 系统很多时候本身并不会与 kafka 结合，加入后还要考虑 partition/HA。消息队列更适合大容量不严格要求精确处理的例子，比如日志，而用户删除账号行为是一个低频且要求严格处理的情况

[HuHui]

楼上这一波不就是典型的过度优化么

[HuHui]

@HuHui 简单的可以通过业务模块来调 service，而不是直接调各个 dao，这样也方便做其他控制，比如事务