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

[smeraldo]

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

[jingxyy]

@Allianzcortex
从业务的角度考虑，你说得没错，isActivate 确实是常用的一种模式。只不过使用消息队列也是一种常用的解耦手段，而且使用消息队列并不意味着一定要引入一套额外的系统，你完全可以参考其思路（类似于 reeco 说的事件驱动解耦）在应用内实现一套类似 django signal 的玩意，这样不但做到了代码解耦，也不影响操作的严格性，想上事务都可以。

[laball]

建议在 Service 和 Dao 之间加一层 Manager，将部分可重用的功能封装起来。
你这里可以封装多个 Manager，每个 Manager 管理一些关联性较强的信息，这样，Service 依赖几个 Manager 即可，每个 Manger 又依赖多个 Dao。这种设计，有点类似门面模式，将复杂的细节进封装，同时，也提高了代码复用度。

我见过有人一个 Service 依赖接近 20 个 Dao 的情况，代码确实不优雅，后期修改起来，有点密集恐惧症。

[zhix]

我同意 @reeco 的方法，使用事件驱动，DeleteService 只负责核心的删除操作，在操作完成之后发布一个事件 UserDeletedEvent，然后业务就结束了。

其他后续的删除操作委托给不同的类去完成，实现类监听 UserDeletedEvent 事件并完成后续的步骤。除此之外，UserDeletedEvent 可以包含 userId、userName 等数据供实现类获取上下文数据。

[smeraldo]

@laball 我现在是这么做的，目前来说还好，但总感觉迭代几次以后中间的 facade dao 也会膨胀，很难符合 srp

[smeraldo]

@zhix 嗯，理想情况下感觉这样做挺好。根据现在的实际情况，增加的复杂度可能没收益来的高

[mokeychan]

我同意 @NoKey 的做法

[woyixinyiyi]

同意 @zhix
我这边也有个类似的，部分 service 有自己的缓存配置，

在定时器类，如果每个都去调用每个 service 的清空缓存，调用 service 太多，定时器发布事件，各类自行清空呗。

[johnniang]

Event-Driven 可以很好的解决这个问题。如果是单体应用的话，就直接用 Spring 自带的 ApplicationEvent ；如果是微服务就用消息中间件吧！