Question

I am designing a WCF service using DDD.
I have a domain service layer that calls repository to create domain objects. The repository is implemented using ADO.Net and not an ORM. The data comes from DB using Stored Procs. While creating an object say an Address the SP returns an id for state. The SP will not join address table with the state table. The state is represented by a value object class State that has id, abbr and name properties. The list of state objects can be cached (using system.runtime.caching.memorycache) when the application starts up as it is non-volatile data. In general I have a LookupDataRepository that can retrieve all such lookup data from tables. Now the AddressRepository has to populate the State property of address from the state id.
pseudo code:

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
}

My question is which layer to put this cache ?. Service, Repository, a separate assembly available across all layers.

Answer 1

Where to put Cache? It depends.
If you’re scenario will be that you inject your IAddressRepository into several application services (I believe you call ’em Domain services) the outcome will be:

• Caching at repository level will result in that all services will benefit (Pros).
• Caching at repository level will result in that all services must use cache (cons).
• Caching at service level will only cache for those clients/service that use that specific service and methods (Pros/Cons?)
• If you have your transaction management at service layer, you’ll need to be careful when applying caching at repository level. Sometime a read operation may hit cache instead and the transaction cannot verify that the read data you’re suppose to conduct write operation on isn’t modified.

I would go for caching at Service layer. If feels more natural and gives you more control of where and when you want to cache. Repository level is usually to low grained. Service layer and its methods is more closer to use cases and it’s then you know when and what to cache.

I really recommend writing a cache wrapper like

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

That holds a static reference to System.Runtime.Caching.MemoryCache.Default.

It makes your Caching type safety and casting is only done inside wrapper. You can also unit test your services with a Mocked ICacheManager injected.

A more advanced approach is to do this with Aspect Oriented Programming and decorators/interceptors. You have tons of good info here at Stack Overflow.