缓存存储库、域或应用程序是否存在问题？

Question

我试图找出哪个层应该负责域驱动设计项目中的缓存（插入/删除）工作。 目标是通过缓存从存储库中检索到的任何实体来提高 Web 应用程序的性能。

我的解决方案分开如下：

MyApp.Infrastracture
MyApp.Repositories
MyApp.Domain
MyApp.WebApplication

我觉得既然只有 Web 应用程序使用缓存，那么缓存逻辑应该是 go 应该是这一层？ 但是，这感觉不正确，因为我想保持 web 应用程序轻量级并专注于服务 web 页面。

缓存也不是第一个 class 域概念，因此在域层中不自然。

该怎么办？

Answer 1

这是上述所有人都关心的问题。

缓存是每个层需要单独处理并且应用程序需要编排的交叉关注点之一。

Answer 2

你注意到

目标是通过缓存从存储库中检索到的任何实体来提高 Web 应用程序的性能。

所以我认为你应该在你的存储库中透明地实现它。 存储库旨在向域隐藏持久性的细节，如果您想缓存大型对象以提高性能，那么域应该是最明智的。 您的存储库必须变得更加智能，可能会跟踪相同 object 的多个副本，因为并行线程请求对象并同时改变它们。 或者——如果可能的话——序列化对单个聚合根的访问，因为它们代表事务边界。

正如@Oded 指出的那样，缓存确实可以在任何地方发生，如果性能是一个问题，您可能会发现自己在很多地方实现它，并且每个地方可能会以不同的方式进行。 例如，您可能会缓存域中某些查询的结果，或者您可能会缓存整个 HTML 响应。

跨层协调的出现是因为缓存可能是一个非常容易泄漏的抽象。 如果你的域对象被缓存了，它们什么时候应该被取消缓存？ 如果一个线程正在使用缓存的 object 而另一个线程没有呢？ 如果您正在缓存查询结果，但底层对象已更改，该怎么办？ 从基础架构角度和业务角度来看，何时失效以及如何失效都是难题。 陈旧的查询并不总是坏事。

Answer 3

我完全同意Oded的观点，即这是一个横切关注点，但它对缓存项目的客户端也应该是透明的。

例如，您的存储库的用户不应该关心项目是否被缓存。

我会争辩说，如果缓存是您解决方案的一个重要方面，那么它应该在域中明确说明，但是，您可能会发现它实际上最终成为基础设施的一部分，并且通过您所使用的任何 IoC 容器（无声地）交付利用。

Answer 4

缓存可以分布在各层之间，如果您使用支持多级缓存的 ORM （如 Nhibernate），有时可以在域层中自动实现缓存。 在上层可以根据需求，例如加载用户时系统加载用户允许执行的功能，然后可以缓存在应用层。 所以这一切都取决于应用程序。