ASP.NET 存储库模式/服务层缓存

Question

我开始为我的 ASP.NET MVC 站点开发缓存基础结构。问题是，我似乎找不到合理的数据缓存位置(“无处不在”除外)

现在我的架构是这样的:

Controller -> 服务层 -> 存储库。存储库使用 Linq to SQL 进行数据访问。

存储库公开了通用方法，例如 Insert、GetById 和 GetQueryable，它们返回一个 IQueryable，服务层可以进一步细化。

我喜欢将缓存放在存储库层的想法，因为服务层不应该真正关心数据的来源。但问题在于缓存失效。服务层比存储库拥有更多关于数据何时变得陈旧的信息。例如:

假设我们有一个 Users 表和一个 Orders 表(典型示例)。服务层提供像 GetOrder(int id) 这样的方法，它会调用存储库层:

public Order GetOrder(int id)
{
    using(var repo = _repoFactory.Create<Order>())
    {
        return repo.GetById(id)
    }
}

或者

repo.GetQueryable(order => order.Id == id && order.HasShipped == false).Single();

如果我们在存储库层中缓存，那么知道订单数据何时更改似乎非常有限。假设用户被删除，导致他们的所有订单都被 CASCADE 删除。服务层可以使订单缓存无效，因为它知道用户刚刚被删除。虽然存储库(因为它是一个工作单元)，但不会知道。 (忽略我们不应该查询已删除用户的订单这一事实，因为这只是一个示例)。

在其他情况下，我认为这很明显。假设我们要获取所有用户订单:

repo.GetQueryable(order => order.UserId == userId).ToList()

存储库可以缓存此查询的结果，但是，如果添加了另一个订单，则此查询不再有效。不过，只有服务层知道这一点。

我对存储库层的理解也可能是错误的。我有点将其视为围绕数据源的外观(即从 L2SQL 更改为 EF 到任何东西，服务层不知道底层源)。

Answer 1

实际上，您将需要另一层；数据缓存层。请求数据时，您的服务层将使用它。根据这样的请求，它将决定是否在缓存中有数据，或者是否需要查询适当的存储库。同样，您的服务层可以告诉这个新的数据缓存层无效(删除特定用户等)。

不过，这对您的架构意味着什么，您的数据缓存层将实现与存储库相同的接口(interface)。一个相当简单的实现将按实体类型和键缓存数据。但是，如果您在幕后使用更复杂的 ORM(NHibernate、EF 4 等)，它应该有缓存作为您的选项。