Тюним запросы в EF Core с помощью интерсепторов

Entity Framework обладает достаточно богатым встроенным языком запросов, позволяющим решать широкий спектр задач. Но бывают ситуации, когда либо сгенерированные с его помощью запросы оказываются недостаточно оптимальными, либо возможности EF покрывают не весь спектр функционала базы.

В этом случае приходится либо генерировать запросы вручную (напрямую, либо с помощью хранимых процедур), либо прибегать к дополнительной обработке сгенерированных запросов с помощью механизма интерсепторов. Рассмотрим работу этого механизма подробнее.

Немного предыстории

Мне пришлось разбираться с интерсепторами, когда возникла необходимость применить запрос вида SELECT … FOR UPDATE в Postgres. Хотя похожий функционал есть и в SQL Server, EF не поддерживает его «из коробки».

Концепт FOR UPDATE прост, несмотря на сложные механизмы «под капотом». Мы просто говорим, что хотим выбрать какие-либо записи для последующего изменения. Начиная с этого момента, и пока мы не отпустим тем или иным способом транзакцию, их нельзя менять, или выбирать в другом SELECT … FOR UPDATE за пределами текущей транзакции. При этом обычные SELECT работают вполне успешно, равно как и изменение других записей.

На уровне кода всё это достигается добавлением FOR UPDATE в конец запроса, но, как я уже сказал, в Entity Framework нет такого функционала. Зато есть функционал интерсепторов, с помощью которого можно решить поставленную задачу.

Интерсепторы

Принцип работы интерсепторов в EF следующий. Интерсепторы перехватывают и позволяют модифицировать сгенерированный SQL запрос перед его отправкой в базу.

По сути, нужно сделать три действия:

1. Объявить класс-интерсептор, который будет модифицировать наш SQL-запрос нужным образом

2. Зарегистрировать интерсептор в системе для указанного контекста работы с базой

3. Как-то передать в него информацию о необходимости активации (если мы не хотим все запросы делать с этой модификацией)

В последнем хорошо помогает механизм тегов. Мы можем промаркировать любой запрос дополнительным тегом, который трансформируется в запросе в комментарий SQL. В результате можем, например, создать класс с расширяющим методом вида:

public static class CommandExtensions {     public static IQueryable<T> ForUpdate<T>(this IQueryable<T> set) where T : class     {         return set.TagWith("FOR UPDATE");     } }

И использовать его примерно следующим образом:

using (ApplicationContext db = new ApplicationContext()) { var trans = db.Database.BeginTransaction(); try     {         var lists = db.Metadata             .Where(p => p.ListId == id)             .ForUpdate()             .ToList();  // код модификации списка trans.Commit();     }     catch     {     trans.Rollback()     throw;     } }

Код интресептора будет выглядеть так. Нам лишь надо убедиться в наличии тега-комментария и применить необходимую трансформацию.

public class ForUpdateInterceptor : DbCommandInterceptor {     public override InterceptionResult<DbDataReader> ReaderExecuting(       DbCommand command,       CommandEventData eventData,       InterceptionResult<DbDataReader> result)     {         if (command.CommandText.Contains("-- FOR UPDATE", StringComparison.InvariantCulture))         {             command.CommandText += " FOR UPDATE";         }         return result;     } }

Класс можно расширить, написав трансформации и для других типов команд ADO.NET. А теперь остаётся только зарегистрировать перехватчик в нашем классе контекста.

public class ApplicationContext : DbContext {     public DbSet<ListMeta> Metadata { get; set; }     public ApplicationContext()     {         Database.EnsureCreated();     }     protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)     {     optionsBuilder.UseNpgsql(/* connection sting */)             .AddInterceptors(new ForUpdateInterceptor());     } }

Вывод

Хотя интерсепторы являются в EF узкоспециализированным инструментом, в некоторых случаях они позволяют существенно экономить время и продолжать использовать EF. Особенно в ситуации, где без них пришлось бы откатываться на написание чистого SQL-кода в самом EF или в хранимых процедурах на стороне базы.