Глобальное кеширование результатов Query в ASP.NET CORE

    Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.


    Пусть все интерфейсы, использующиеся в рамках запроса будут иметь тип IQuery или IAsyncQuery:


    public interface IQuery<TIn, TOut>
    {
       TOut Query(TIn input);
    }
    
    public interface IAsyncQuery<TIn, TOut>: IQuery<TIn, Task<TOut>
    {
    }

    Эти интерфейсы полно описывают получение данных, например, получение отформатированных цен с учетом скидок/бонусов и всего прочего:


    public class ProductPriceQuery: IQuery<ProductDto,PricePresentationDto>
    {
      public ProductPriceQuery(
         IQuery<ProductDto, PriceWithSalesDto> priceWithSalesQuery,
         IQuery<PriceWithSalesDto, PricePresentationDto> pricePresentationQuery)
      {
         _priceWithSalesQuery = priceWithSalesQuery;
         _pricePresentationQuery = pricePresentationQuery;
      }
    
      public PricePresentationDto Query(ProductDto dto) 
      {
         var withSales = _priceWithSalesQuery(dto);
         var result = _pricePresentationQuery(withSales);
         return result;
      }
    }

    Pipeline интерфейсов


    Плюс такого подхода — единообразие интерфейсов в приложении, которые можно выстраивать в pipeline:


    public class Aggregate2Query<TIn, TOut1, TOut2> : BaseAggregateQuery<TIn, TOut2>
     {
       public Aggregate2Query(
          IQuery<TIn, TOut1> query0,
          IQuery<TOut1, TOut2> query1)
          : base(query0, query1){}
     }
    
    public abstract class BaseAggregateQuery<TIn, TOut> : IQuery<TIn, TOut>
     {
       private object[] queries { get; set; }
    
       protected BaseAggregateQuery(params object[] queries)
       {
           this.queries = queries;
       }
    
       public TOut Query(TIn input) =>
           queries.Aggregate<object, dynamic>(input, (current, query) =>
           ((dynamic) query).Query(current));
     }

    Регистрировать вот так:


    serviceCollection.AddScoped(typeof(Aggregate2Query<,,>));

    Получаем:


    public ProductPriceQuery(
       BaseAggregateQuery<ProductDto,PriceWithSalesDto,PricePresentationDto>  query)
    {
      _aggregateQuery = query;
    }
    
    public PricePresentationDto Query(ProductDto dto) => _aggregateQuery.Query(dto);

    В идеале программирование должно превратиться в сборку конструктора, но на деле это просто красивая фишечка для удовлетворения самолюбия программиста.


    Декораторы и ASP.NET CORE


    Библиотека MediatR построена как раз на единообразии интерфейсов и на декораторах.


    Декораторы позволяют навесить на стандартный интерфейс IQuery<TIn, TOut> некоторые дополнительные функции, например логгирование:


    public class LoggingQuery<TIn,TOut>: IQuery<TIn,TOut>
    {
       public LoggingQuery(IQuery<TIn,TOut> priceQuery)
       {
          _priceQuery = priceQuery
       }
    
       public TOut Query(TIn input)
       {
         Console.WriteLine($"Query {_priceQuery.GetType()} Start");
         var result= _priceQuery.Query(input);
         Console.WriteLine($"Query {_priceQuery.GetType()} End");
         return result; 
       }
    }

    Я опущу то, что декораторы позволяют написать сквозную(cross-cutting) функциональность в одном месте, а не размазывать по всей программе, это не входит в рамки данной статьи.


    Стандартный IoC контейнер предоставляемый .Net Core не умеет регистрировать декораторы.Сложность в том что у нас есть две реализации одного интерфейса: исходная query и декоратор, и в конструктор декоратора приходит тот же интерфейс, который декоратор реализует. Контейнер не может разрешить такой граф и кидает ошибку "circular dependency".


    Есть несколько путей решения этой проблемы.Специально для .Net Core контейнера написана библиотека Scrutor, она умеет регистрировать декораторы:


     services.Decorate(typeof(IQuery<,>), typeof(LoggingQuery<,>));

    Если вы не хотите добавлять в проект лишние зависимости, то можно написать этот функционал самому, что я и сделал. Перед демонстрацией кода давайте обсудим кеширования результатов Query в рамках запроса. Если нужно добавить кеширование и ключом является класс, необходимо переопределить GetHashCode и Equals, так мы отвяжемся от сравнения по ссылке.


    Способы кеширования


    Я представлю пример простого кеша:


    //Cache
     ConcurrentDictionary<Key,Value> _cache { get; }
    //Key
     public class Key
     {
       //ReSharper-generated code
       protected bool Equals(Key other)
       {
          return Field1 == other.Field1 && Field2 == other.Field2;
       }
       //ReSharper-generated code
       public override bool Equals(object obj)
       {
           if (ReferenceEquals(null, obj)) return false;
           if (ReferenceEquals(this, obj)) return true;
           if (obj.GetType() != this.GetType()) return false;
           return Equals((Key) obj);
       }
       //ReSharper-generated code
       public override int GetHashCode()
       {
           unchecked
           {
               return (Field1 * 397) ^ Field2;
           }
       }
    
       public int Field1 { get; set; }
       public int Field2 { get; set; }
    }
    //Value irrelevant

    При поиске значения сначала вызывается метод GetHashCode для поиска нужной корзины, а потом, если в корзине более одного элемента, вызывается Equals для сравнения.Посмотрите, если не совсем понимаете как это работает


    ReSharper сам генерирует эти методы, но мы реализуем кеширование глобально, об этом не обязан знать программист реализовавший IQuery<TIn, TOut> интерфейс и вообще интерфейс IQuery<TIn,TOut>, не будем забывать об SRP. Поэтому генерация методов решарпером нам не подходит.


    Когда мы имеем дело со сквозной функциональностью на помощь приходят АОП фреймворки. EqualsFody, плагин для Fody, переписывает IL, переопределяя Equals и GetHashCode в классах помеченных атрибутом EqualsAttribute.


    Чтобы не помечать каждый Dto этим атрибутом мы можем немного переписать интерфейс IQuery


    public IQuery<TIn,TOut> where TIn : CachedDto{
    
    }
    
    [Equals]
    public class CachedDto{
    
    }

    Теперь все Dto точно будут переопределять нужные методы, и нам не нужно добавлять атрибут на каждый входной DTO (он будет подхвачен из базового класса). Если перезаписывать IL вам не подходит, реализуйте CachedDto так (используем контекст в котором вызываются методы базового класса):


    public class CachedDto{
      public override bool Equals(object x) => DeepEquals.Equals(this,x);
      public override int GetHashCode() => DeepHash.GetHashCode(this);
    }

    DeepEquals.Equals и DeepHash.GetHashCode используют рефлексию, будет медленнее чем Fody, для корпоративных приложений не фатально.


    Но вспоминаем про SRP, IQuery не должен знать про то, что его кешируют.


    Наиболее верным решением будет реализация IEqualityComparer. Dictionary принимает его в конструкторе и использует при вставке/удалении/поиске.


     public class EqualityComparerUsingReflection<TKey> : IEqualityComparer<TKey>
     {
       public bool Equals(TKey x, TKey y) => DeepEqualsCommonType(x, y);
    
       public int GetHashCode(TKey obj) => Hash.GetHashCode(obj);
     }

    Теперь можно выкинуть constraint на TIn, мы добились чего хотели. Напишем кеширующий декоратор:


     public class BaseCacheQuery<TIn, TOut> : IQuery<TIn, TOut>
     {
        private readonly ConcurrentDictionary<TIn, TOut> _cache;
    
        private readonly IQuery<TIn, TOut> _query;
    
        protected BaseCacheQuery(
            IQuery<TIn, TOut> query,
            IConcurrentDictionaryFactory<TIn, TOut> factory)
        {
            _cache = factory.Create();
            _query = query;
        }
    
        public TOut Query(TIn input) => _cache
            .GetOrAdd(input, x => _query.Query(input));
      }
    

    Обратите внимание на IConcurrentDictionaryFactory, цель этой фабрики предоставить экземпляр словаря, но почему бы просто не создать его в конструкторе?


    Во-первых, DI и SRP, вполне возможно, что нужно будет добавить еще одну реализацию компарера(например более легкую для определенных типов DTO) или вообще поменять реализацию, во-вторых, возможна ситуация, когда кеш начнет тормозить из-за рефлексии и абстрация протечет. Я пойду на компромисс и если в Dto переопределены Equals и GetHashCode не буду использовать "тяжелый" EqualityComparer.


    Цель фабрики — проверить переопределены ли методы, если да, вернуть стандартный словарь, использующий переопределенные в DTO методы, нет — словарь с компарером.


    Регистрация


    Вернемся к тому, как все это регистрировать.


    Аргумент services метода ConfigureServices это коллекция ServiceDescriptor'ов, каждый дескриптор содержит информацию о регистрируемой зависимости


    public class ServiceDescriptor{
        // other methods
    
        /// <inheritdoc />
        public ServiceLifetime Lifetime { get; }
    
        /// <inheritdoc />
        public Type ServiceType { get; }
    
        /// <inheritdoc />
        public Type ImplementationType { get; }
    
        /// <inheritdoc />
        public object ImplementationInstance { get; }
    
        /// <inheritdoc />
        public Func<IServiceProvider, object> ImplementationFactory { get; }
    
      // other methods
    }

    Таким образом в коллекцию services добавляется новый ServiceDescriptor с LifeTime = Scoped,
    ServiceType = typeof(IService), ImplementType = typeof(Service) :


    services.AddScoped<IService,Service>().

    Свойство ImplementationFactory позволяет конкретно указать, как нужно создавать зависимость, мы будет использовать его. Я напишу extension к IServiceCollection, который найдет в сборках все IQuery и IAsyncQuery, навесит декораторы и зарегистрирует.


     public static void AddCachedQueries(this IServiceCollection serviceCollection)
     {
       // Func<Type,bool>  выбирает типы реализующие IAsyncQuery
         var asyncQueryScanPredicate = AggregatePredicates(
         IsClass, ContainsAsyncQueryInterface);
    
        // Func<Type,bool> который выбирает типы реализующие IQuery
         var queryScanAssemblesPredicate =AggregatePredicates(
          IsClass, x => !asyncQueryScanPredicate(x), ContainsQueryInterface);
    
         // находит все реализации IAsyncQuery в сканируемых сборках
         var asyncQueries = GetAssemblesTypes(
         asyncQueryScanPredicate, DestAsyncQuerySourceType);
         // находит все реализации IQuery в сканируемых сборках
         var queries = GetAssemblesTypes(
         queryScanAssemblesPredicate, DestQuerySourceType);
         //регистрация фабрики создающую ConcurrentDictionary
         serviceCollection.AddScoped(
         typeof(IConcurrentDictionaryFactory<,>), typeof(ConcDictionaryFactory<,>));
         // добавляет в services ServiceDescriptor'ы для регистрации IAsyncQuery
         serviceCollection.QueryDecorate(asyncQueries, typeof(AsyncQueryCache<,>));
         // добавляет в services ServiceDescriptor'ы для регистрации IQuery
         serviceCollection.QueryDecorate(queries, typeof(QueryCache<,>));
       }
    
       private static void QueryDecorate(this IServiceCollection serviceCollection,
           IEnumerable<(Type source, Type dest)> parameters, Type cacheType,
           ServiceLifetime lifeTime = ServiceLifetime.Scoped)
       {
           foreach (var (source, dest) in parameters)
               serviceCollection.AddDecorator(
                  cacheType.MakeGenericType(source.GenericTypeArguments),
                  source,
                  dest,
                  lifeTime);
       }
    
        private static void AddDecorator(
           this IServiceCollection serviceCollection,
           Type cacheType, Type querySourceType,
           Type queryDestType,
           ServiceLifetime lifetime = ServiceLifetime.Scoped)
       {
        //ReSharper disable once ConvertToLocalFunction  
        Func<IServiceProvider, object> factory = provider 
           => ActivatorUtilities.CreateInstance(provider, cacheType,
           ActivatorUtilities.GetServiceOrCreateInstance(provider, queryDestType));
    
        serviceCollection.Add(
           new ServiceDescriptor(querySourceType, factory, lifetime));
       }
    }

    Особого внимания заслуживает метод AddDecorator, здесь используются статические методы класса ActivatorUtilities. ActivatorUtilities.CreateInstance принимает IServiceProvider, тип создаваемого объекта и экземпляры зависимостей которые этот объект принимает в конструкторе(можно указать только те, которые не зарегистрированы, остальные будут разрешены провайдером)


    ActivatorUtilities.GetServiceOrCreateInstance — делает тоже самое, но не позволяет передавать в конструктор создаваемого объекта недостающие зависимости. Если объект зарегистрирован в контейнере то он просто создаст его(либо вернет уже созданный), если же нет, создаст объект, при условии, что сможет решить все его зависимости


    Тем самым можно создать функцию возвращающую объект кеша и добавить в services дескриптор описывающий эту регистрацию.


    Напишем тест:


    public class DtoQuery : IQuery<Dto, Something>
    {
       private readonly IRepository _repository;
    
       public DtoQuery(IRepository repository)
       {
          _repository = repository;
       }
    
       public Something Query(Dto input) => _repository.GetSomething();
    }
    // инициализация из контейнера
    private IQuery<Dto, Something> query { get; set; }
    
    public void TwoCallQueryTest()
    {
       var dto = new Dto {One = 1};
       var dto1 = new Dto {One = 1};
       //query - зарегистрирован нашим расширением и получены из контейнера
       query.Query(dto);
       query.Query(dto1);
       //за кулисами: services.AddScoped<IRepository>(x => MockRepository.Object)
       RepositoryMock.Verify(x => x.GetSomething(), Times.Once);
    }

    ReposityMock — Mock от библиотеки Moq, забавно, но для тестирования того, сколько раз был вызван метод GetSomething() репозитория она тоже использует декораторы, правда генерирует их автоматически используя Castle.Interceptor. Мы тестируем декораторы используя декораторы.

    Вот так можно добавить кеширование всех результатов IQuery<TIn,TOut>, очень неудобно писать столько кода чтобы реализовать небольшую функциональность.


    Другие решения


    MediatR


    Центральный интерфейс библиотеки:


    public interface IRequestHandler<in TRequest, TResponse> 
      where TRequest : IRequest<TResponse>
    {
      Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken);
    }

    Основная функциональность MediatR — добавление оберток над IRequestHandler'ом, например, реализация pipeline с помощью интерфейса IPipelineBehavior, вот так можно зарегистрировать CachePipelineBehaviour, он будет применяться ко всем зарегистрированным интерфейсам IRequestHandler:


    sc.AddScoped(typeof(IPipelineBehavior<,>), typeof(CachePipelineBehaviour<,>));

    Реализуем кеширующий PipelineBehaviour:


    public class CachePipelineBehaviour<TDto, TResult> 
                    : IPipelineBehavior<TDto, TResult>
    {
      private readonly ConcurrentDictionary<TDto, Task<TResult>> _cache;
    
      public CachePipelineBehaviour(
          IConcurrentDictionaryFactory<TDto, Task<TResult>> cacheFactory)
      {
          _cache = cacheFactory.Create();
      }
    
       public async Task<TResult> Handle(TDto request, 
          CancellationToken cancellationToken,
          RequestHandlerDelegate<TResult> next) =>
          await _cache.GetOrAdd(request, x => next());
    }

    В метод Handle приходит Dto запроса, токен отмены и RequestHandlerDelegate. Последний это просто обертка над следующими вызовами других декораторов и handler'a. MediatR сканирует сборки и сам регистрирует все реализации интерфейса. Чтобы воспользоваться вам нужно инжектировать IMediator, и вызвать у него метод Send передав Dto:


    public async Task<IActionResult>([FromBody] Dto dto){
        return Ok(mediator.Send(dto));
    }

    MediatR сам найдет найдет подходящую реализацию IRequestHabdler'a и применит все декораторы (Кроме PipelineBehaviour есть еще IPreRequestHandler и IPostRequestHandler)


    Castle Windsor


    Фишка контейнера — генерация динамических оберток, это динамическое АОП.


    Entity Framework использует его для Lazy Loading, в геттере свойства вызывается метод Load интерфейса ILazyLoader, который инжектируется в классы всех оберток над сущностями через внедрение конструктора.


    Чтобы сконфигурировать контейнер с генерацией оберток нужно создать Interceptor и зарегистрировать его


      public  class CacheInterceptor<TIn, TOut> : IInterceptor
     {
       private readonly ConcurrentDictionary<TIn, TOut> _cache;
    
       public CacheInterceptor(
             IConcurrentDictionaryFactory<TIn, TOut> cacheFactory)
       {
           _cache = cacheFactory.Create();
       }
    
       public void Intercept(IInvocation invocation)
       {
           var input = (TIn) invocation.Arguments.Single();
           if (_cache.TryGetValue(input, out var value))
               invocation.ReturnValue = value;
           else
           {
               invocation.Proceed();
               _cache.TryAdd(input, (TOut) invocation.ReturnValue);
           }
         }
     }

    Интерфейс IInvocation предоставляет информацию о члене декорируемого объекта, к которому было обращение, единственный публичный член интерфейса это метод Query, поэтому не будем ставить проверки, что обращение было именного к нему, других вариантов нет.


    Если в кеше есть объект с таким ключом, заполним возвращаемое значение метода (не вызывая его), если же нет, вызовем метод Proceed, который, в свою очередь, вызовет декорируемый метод и заполнит ReturnValue.


    Регистрацию перехватчика и полный код можно посмотреть на Githab

    Поделиться публикацией

    Похожие публикации

    Комментарии 10

      +1
      Парадигма CQRS в том или ином виде предполагает, что вызовы Query не будут менять состояние приложения. То есть многократные вызовы одной и той же query, в рамках одного запроса, будут иметь один и тот же результат.

      НЕЕЕЕ, НУ ТАК НЕ ИНТЕРЕСНО....

        +2
        А кстати с чего вдруг такое допущение? Геттеры не меняют, а вот параллельно вызванные сеттеры очень даже.
        +2
        Не обязательно было разделять на IQuery и IAsyncQuery, можно в out передать Task.
          +1

          Это не очень хорошее решение, работа с асинхронным кодом отличается даже на уровне компилятора. Поэтому не стоит объединять это под одним интерфейсом, интерфейс должен быть явным. Да и каждый раз оборачивать возвращаемое значение IQuery в Task ужасно.
          Написать один раз вот так легче:


          public interface IAsyncQuery<TIn, TOut>: IQuery<TIn, Task<TOut>
          {
          }
            0
            Код хендлера
            Контроллер
            Закостыливание разделением портит картину. Отсутствие ковариации. И метод кстати все равно у вас асинхронный. На уровне компилятора все так же будет, напишите await — сгенерится стейтмашина.
          +1
          Пытался прочесть статью внимательно.

          Не смог. Попахивает велосипедом, щедро сдобренным непонятными абстракциями.

          При этом не видно
          1) Универсальности кода
          2) Простоты синтаксиса
          3) Прозрачной архитектуры

          Может быть написано сумбурно, но я не нашел ничего такого, что нельзя было сделать не выходя за рамки архитектуры EF и LINQ. Абстракции ради абстракция лишь утяжеляют код.
            0
            но я не нашел ничего такого, что нельзя было сделать не выходя за рамки архитектуры EF и LINQ.


            Интерфейсы, описанные в статье, не имеют отношения к слою доступа данных. Это более высокий слой приложения
              0
              Что мешает тогда оформить все это в виде сервиса/датасервиса?
                0
                Реализации данных интерфейсов по сути и представляют application services. Единообразный интерфейс необходим, чтобы единообразно применять cross-cutting concerns.
            0

            Как с помощью датасета неявно закешировать результаты Query? Тут скорее вопрос методологии и вам CQRS не нравится

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое