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

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

Разработчики периодически разрываются между желанием логировать как можно больше информации и необходимостью сделать объём логов разумно компактным.

Когда речь идёт о небольшом локальном сервисе с нагрузкой 10 запросов в день, можно позволить себе писать в логи всё: от полного текста запроса до полного текста ответа с кучей промежуточной информации (что пришло из базы, какой запрос послали во внешний сервис и что получили в ответ и т.д.). Когда же речь об относительно высоконагруженном сервисе, обрабатывающем порядка 1000 rps даже малая часть этой информации за пару дней запросто может вызвать переполнение современного жёсткого диска.

Возникает логичный вопрос: как логировать только нужную информацию?

Давным-давно, во времена, когда по Земле бродили цифровые динозавры, а разработчики .NET ещё помнили, зачем нужна технология WebForms (и какие у неё были проблемы с производительностью), в Контуре появился продукт под названием Фокус, предназначенный для проверки контрагентов. И у этого продукта довольно быстро появился API, ориентированный на крупных клиентов.

ASP.NET MVC был ещё в новинку, до появления WebAPI оставались годы, и отцы-основатели проекта приняли вполне актуальное, с учётом реалий того времени, решение: делать API на базе ashx-хендлеров, чтобы максимально повысить скорость работы.

Шли годы, .NET Framework сперва меняла версии как ветреная красавица перчатки, а потом и вовсе перешла в разряд «для поддержки жизнедеятельности требуется опытный некромант», .NET Core сперва появился, а потом благополучно переименовался в просто .NET, дорос до 6-й, а потом и 7-й версии… а API Фокуса всё ещё жил по старому, доброму принципу «работает — не трогай». И вот, наконец небосвод провернулся, и звёзды сошлись в нужной позиции. Мы поехали на .NET 6.

Оговорюсь сразу, что сам переезд произошёл примерно полгода назад, когда .NET 8 ещё находилась в стадии альфы. Именно поэтому в качестве целевой версии .NET была выбрана именно стабильная 6-я. Тем не менее большинство проблем будут актуальны и при миграции на 8-ю версию.