后端程序分层的问题

[chaleaochexist]

更新数据库的同时 紧跟着更新缓存, 这个缓存不是 redis 缓存, 而是一个 local 的 hashmap
譬如, 数据库的结构体是 ConfigModel 这个 map 是[id]ConfigModel 的类型.

这两步操作是否可以放到一起, 到 repo 层来处理

譬如 ConfigRepo.UpdateConfig(configModel){
ConfigModel.updateDB(configModel)
localCache.update(configModel)
}
还是说两个操作要分开, 在 service 中分别调用?

[crysislinux]

你可以在 service 发一个写入的 event ，cache 的部分加一个 hook 来处理 event ，这样逻辑上就解耦了

[zhudan]

还在研究这玩意儿呢，是我穿越了么

[chaleaochexist]

@zhudan 又被嘲笑了. sad

[zh3256]

代码分层是为了对人更友好，目前的情况可以试着对大模型更友好一些，减少分层，让模型一次尽量拿全信息。

[Ayanokouji]

强一致性可以考虑事务，将缓存放到事务中，优雅点的的写法，可以参考 spring 的 transaction event ，使用 event 。
非强一致性，这样写也不会有多大问题，大不了查询的时候再查一遍，除非你业务能达到缓存穿透的并发量，不然两者没啥差别。

ps：求学有什么可嘲笑，啥都不懂就能用好大模型了吗

[credo123]

我这面是直接在 repository 层方法里处理了。缓存（ redis/caffine ）+DB （ JPA/mybatis ）。repository 监控指标也底层改了下，监测到有 sql 执行才会记录指标。
开发人员多的情况下，一个 model 层对应的缓存处理只在 repository 层方便所有人通用。如果是在 service ，代码多起来很难看，很难通用。如果是 springCache 那种，注解散在各个 service 中，实际开发会很难受。
service 就处理业务，别让他参合 DB 层的东西了，不管是 DB 的缓存还是直接取 DB 的数据。
我也考虑过，再多一个缓存层，后来想来想去觉得没必要就没搞。