在业务层缓存与在数据层缓存

我一直在使用DAL进行缓存的项目中工作，基本上只是在您要对数据库进行调用时，它会检查缓存中是否已经有数据，如果存在，它不会进行调用，并且而是返回该数据。

我最近才读到有关在业务层进行缓存的信息，因此基本上可以缓存整个业务对象。我可以立即看到的一个优势是响应时间更快。

您什么时候比另一个更喜欢？并且在业务层缓存是一种常见的做法吗？

对于确定的答案，这可能太宽泛了。就我个人而言，我认为数据访问层是缓存的最佳场所，仅因为它应该非常简单-记录可以进出，仅此而已。

业务层实现了许多其他复杂性更高的规则，因此最好不要在同一类（甚至同一方法）中除了管理多对象一致性问题外，还不必管理每个对象的可用性问题。公然违反SRP。

（当然，当我的服务类尝试同时进行缓存和配置时，我的服务类变得越来越难以控制，我只有在获得了深刻见解之后，再没有比经验更好的老师了，但是价格肯定很高。）

数据访问和持久性/存储层是不可抗拒的自然缓存地方。他们在做I / O，使它们成为方便，容易插入缓存的地方。我敢说，几乎每个DAL或持久层都将随着其成熟而被赋予缓存功能-如果从一开始就不是那样设计的。

问题是故意的。DAL和持久层处理相对较低级别的构造，例如记录，表，行和块。他们看不到“业务”或应用程序层对象，也没有深入了解如何在更高级别使用它们。当他们看到要读取或写入的几行或十几个块时，不清楚它们代表什么。“我们目前正在分析的Jones帐户”与“该应用仅需要一次且不会再次引用的一些基本税率参考数据”看起来并没有太大不同。在这一层，数据就是数据就是数据。

在DAL /持久层进行缓存的风险在于，有“冷”税收参考数据位于那里，毫无意义地占用了12.2MB的缓存，并且替换了一些帐户信息，而事实上，这些信息将在短短一分钟内被大量使用。即使是最好的高速缓存管理器，也很少处理高级数据结构和连接的知识，对即将到来的操作知之甚少，因此他们只能依靠猜测算法。

相比之下，应用程序或业务层缓存并不是那么整洁。它要求在其他业务逻辑中间插入缓存管理操作或提示，这会使业务代码更加复杂。但是要权衡一下：了解更多有关宏级数据的结构和即将进行的操作的知识，它有更好的机会来近似最佳（“千里眼”或“贝拉迪·敏”）缓存效率。

将缓存管理职责插入业务/应用程序代码是否有意义是一个判断调用，并且会因应用程序而异。在许多情况下，虽然已知DAL /持久层不能做到“完全正确”，但要权衡的是它们可以做得很好，它们可以在架构上“干净”并且可以进行更深入的测试，并且这种低级别的捕获避免了增加业务/应用程序代码的复杂性。

较低的复杂度可提高准确性和可靠性，并加快产品上市时间。通常认为这是一个很好的折衷方案-不太完善的缓存，但是质量更高，更及时的业务代码。

DAL上的缓存既简单又简单

您的DAL是中央数据访问层，这意味着可以通过那里的类来控制任何数据访问。由于读取和持久化都发生在这些层上，因此随着更改的发生，清除或更新缓存条目同样容易。

业务缓存非常灵活

对业务进行缓存使开发人员可以灵活地确定对象的具体用法是否将从缓存中受益。根据应用程序的结构，后端服务或自动化过程可能会更改其他部分中缓存的数据。通过缓存业务，开发人员可以确定某个业务对象是否将具有过时的数据并获得性能，或者以牺牲性能为代价来确定业务对象的最新状态。