Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
990 views
in Technique[技术] by (71.8m points)

dns - Caching Code Location in a Domain Driven Design

In an application that has followed a Domain Driven Design where you have the following sorts of concepts

  1. A repository that deals with the DataBase access
  2. A application service that co-ordinates interactions between enties and value objects etc.

where in general would you put caching code to elimenate an expensive call to the database?

I have seen code bases that just cache all over the place and it is difficult to monitor memory usage and difficult to provide guidelines to other developers.

Please understand that I know you should only cache data when you need to, I am just asking a general question.

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

The wonderful thing about abstract Repositories is that you can use the Decorator pattern to implement such cross-cutting concerns as caching.

As an example, given an IMyRepository interface, you can create a MyCachingRepository like this pseudo code:

public class MyCachingRepository : IMyRepository
{
    private readonly IMyRepository repository;

    public MyCachingRepository(IMyRepository repository)
    {
        if(repository == null)
        {
            throw new ArgumentNullException("repository");
        }

        this.repository = repository;
    }

    public Foo SelectFoo(int id)
    {    
        Foo foo = ... // attempt to get foo from cache

        if // foo is not it cache
        {
            foo = this.repository.SelectFoo(id);
            // save foo in cache
        }
        return foo;
    }
}

In this example, GetFoo is defined by IMyRepository. Notice how the decorated Repository is only invoked if the item isn't found by the cache.

This follows the Single Resposibility Principle because the real caching implementation can concentrate on retrieving and saving data, whereas the caching Decorator can concentrate on caching. This lets you vary the two independently of each other.

In our current project we used this approach, and what is extra nice is that we could do it as an afterthought without even touching the original Repositories. This is in spirit of the Open/Closed Principle.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...