项目分层中，缓存应该放在哪儿

Posted on 2023-09-20 In Coding

引言

设计一个高效且完善的业务系统，通常会需要分层。目前主流的分层都大多包含三层delivery, service, repository。当然，我们有时会在这些基础层次之间进行扩展，如在service和repository之间加入一个manager层，正如阿里的架构那样。

层架构下每个层的职责变得清晰，利于实现业务逻辑已经开展迭代。

但是，在设计业务逻辑的时侯，我遇到了一个问题，也就是缓存。究竟是放在service 层更好还是 repository 层更好捏？

从大方向上来看，一群人认为，service不应干涉数据的来源。而另一群人认为，是否使用缓存的选择是一个业务逻辑决策。当然每个观点都有他的合理性。下面，我将对这两个观点进行对比分析：

优点:

数据源无关性：将缓存逻辑放在repository层，数据的来源对上层是透明的，这意味着Service层或Use Case层不需要知道数据是从缓存中取得还是从数据库或远程API取得。
一致性：所有数据的访问，无论是从缓存还是直接从主数据源，都会通过repository层，确保数据的检索和管理方式始终一致。
可重用性：不同的service可能需要相同的数据。如果缓存在repository层实现，可以跨多个service重用缓存，而无需复制逻辑。如果有多个Service或Use Case需要访问相同的数据，它们都可以自动从缓存中受益，而不需要每次都实现缓存逻辑。

缺点:

缺乏灵活性：并不是所有service都需要缓存数据，可能对某些业务逻辑来说，总是从缓存中获取数据并不合适。例如，某些业务逻辑可能需要最新的、未缓存的数据。

优点:

细粒度控制：可以根据特定的使用场景来调整缓存，从而在数据缓存的时间和方式上具有更大的灵活性。提供了更大的灵活性。业务逻辑可以决定何时使用缓存，何时直接从数据源获取。对于需要特定缓存策略的复杂业务逻辑，这种方法更为合适。
优化性能：只有最关键的操作可能需要缓存，将这个逻辑放在service层可以针对性地提高性能。

缺点:

我倾向于将缓存逻辑放在Repository层。这样可以确保数据的来源对上层是透明的，并减少代码重复。但是，这并不是一种一刀切的策略。在某些情况下，特别是当业务逻辑有特定的缓存需求时，将缓存逻辑放在Service层或Use Case层可能更为合适。

关键是要确保你的选择能够满足项目的需求，同时还要考虑到代码的维护性和可读性。