我应该在 DDD 应用程序中的哪一层实现数据库查找数据的缓存？

Question

我正在使用 DDD 设计 WCF 服务。 我有一个域服务层，它调用存储库来创建域对象。该存储库是使用 ADO.Net 而不是 ORM 实现的。数据来自使用存储过程的数据库。当创建一个对象时，比如说一个地址，SP 返回一个状态 ID。 SP不会将地址表与状态表连接起来。状态由具有 id、abbr 和 name 属性的值对象类 State 表示。当应用程序启动时，状态对象列表可以被缓存（使用 system.runtime.caching.memorycache），因为它是非易失性数据。一般来说，我有一个 LookupDataRepository 可以从表中检索所有此类查找数据。现在，AddressRepository 必须从州 ID 填充地址的 State 属性。
伪代码：

class AddressRepository : IAddressRepository
{
    Address GetAddressById(int id)
    {
        // call sp and map from data reader
        Address addr = new Address(id);
        addr.Line = rdr.GetString(1);
        addr.State = // what to do ?, ideally LookupCache.GetState(rdr.GetInt32(2))
    }
}

class State
{
    public int Id;
    public string Abbr;
    public string Name;
    enum StateId {VIC, NSW, WA, SA};
    public static State Victoria = // what to do, ideally LookupCache.GetState(StateId.VIC)
}

// then somewhere in address domain model
if(currentState = State.Victroia)
{
    // specific logic for Victoria
}

我的问题是把这个缓存放在哪一层？服务、存储库、跨所有层可用的单独程序集。

Answer 1

缓存放在哪里？这取决于。
如果您的场景是将您的 IAddressRepository 注入多个应用程序服务（我相信您称之为域服务），结果将是：

• 在存储库级别进行缓存将导致所有服务都受益（优点）。
• 存储库级别的缓存将导致所有服务都必须使用缓存（缺点）。
• 服务级别的缓存只会缓存那些使用特定服务和方法的客户端/服务（优点/缺点？）
• 如果您在服务层进行事务管理，那么在存储库级别应用缓存时需要小心。有时，读取操作可能会命中缓存，并且事务无法验证您要执行写入操作的读取数据是否未被修改。

我会在服务层进行缓存。如果感觉更自然，并且可以让您更好地控制要缓存的位置和时间。存储库级别通常是低粒度的。服务层及其方法更接近用例，这样您就知道何时缓存以及缓存什么内容。

我真的建议编写一个缓存包装器，例如

public class CacheManager : ICacheManager
{
 public Address Address
        {
            get { }
            set { }
        }
}

它保存对 System.Runtime.Caching.MemoryCache.Default 的静态引用。

它使您的缓存类型安全，并且转换仅在包装器内部完成。您还可以使用注入的模拟 ICacheManager 来对您的服务进行单元测试。

更高级的方法是使用面向方面的编程和装饰器/拦截器来做到这一点。 Stack Overflow 上有大量有用的信息。

Answer 2

根据我的观点和我的经验，缓存作为存储库会导致重复代码、增加域的复杂性以及所有事件都需要缓存吗？由于将实现 IRepository 接口......
所以我选择了基础设施服务，让我们只缓存应用程序中需要的内容。它也可供所有其他希望使用它的服务使用。