Картинка в начале статьи, вообще-то, служит для привлечения внимания читателей. Она так и называется: "картинка для привлечения внимания", сокращённо — КДПВ.
Впрочем, а данной статье я отступил от традиции брать в качестве КДПВ какой-нибудь переделанный мем или нечто абстрактное, созданное нейросетью, а использовал иллюстрацию по теме статьи. В данном случае на картинке схематически изображен один из сценариев выполнения кода в фоновом режиме. А рассказать об этом подробнее можно только с использованием несколько новых понятий, изложенных в статье. То есть — прочитать значительную часть статьи. Поэтому подробное объяснение помещено ближе к концу статьи.

Введение

Общее описание библиотеки ActiveSession

• Для чего предназначена эта библиотека
• Компоненты библиотеки ActiveSession и ее расширений
  
  • Исполнители
  • Объекты активных сеансов
  • Инфраструктура библиотеки ActiveSession
  • Фабрики исполнителей

Начало работы с библиотекой ActiveSession

• Подключение библиотеки ActiveSession к приложению
• Выбор классов для исполнителей
• Конфигурирование сервисов
• Добавление в конвейер веб-приложения обработчика инфраструктуры библиотеки ActiveSession

Использование библиотеки ActiveSession в обработчиках запросов к веб-серверу.

Заключительные замечания.

• Зачем была написана библиотека ActiveSession
• Лицензия.
• Ограничения.
• Об отладке и тестах.
• Наблюдаемость AKA observability.
• Документация и примеры.
• Перспективы.

Примеры в скрытом тексте, для которых указаны имена файлов, откуда взяты примеры (жирным шрифтом), содержатся в проекте SampleApplication в репозитории с примерами использования библиотеки (ссылка — выше). Имена файлов указаны относительно корневой папки этого проекта.

То есть, для выполнения своих функций в приложении и для взаимодействия с остальными компонентами (инфраструктурой) библиотеки ActiveSession исполнитель должен быть оформлен в виде класса, реализующего интерфейс IRunner<TResult>. Это — обобщенный интерфейс, его единственный параметр-тип (TResult) — это тип результата операции, производимой исполнителем. Часть свойств и методов интерфейса исполнителя от типа результата не зависит. Эти свойства и методы вынесены в отдельный, типонезависимый (иначе говоря, не обобщенный) интерфейс исполнителя — IRunner. Технически упомянутый выше обобщенный (полный) интерфейс исполнителя IRunner<TResult> является наследником типонезависимого интерфейса исполнителя IRunner, а потому класс исполнителя, обязанный реализовывать полный интерфейс исполнителя автоматически реализует и типонезависимый интерфейс.

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

• EnumAdapterRunner<TItem> — создает исполнитель с типом результата IEnumerable<TItem>, возвращающий результаты от выполняющегося в фоне процесса, возвращающего последовательность записей типа TItem также с помощью интерфейса IEnumerable<TItem>;
• AsyncEnumAdapterRunner<TItem> — аналогично предыдущему, но источником записей служит интерфейс IAsyncEnumerable<TItem>;
• TimeSeriesRunner<TResult> — возвращает последовательность пар типа (DateTime,TResult), получаемых вызовом заданной через входной параметр функции, вызываемой в моменты времени с заданным интервалом, т.е. имеет тип результата IEnumerable<ValueTuple<DateTime,TResult>>;
• SessionProcessRunner<TResult> — запускает в фоновом режиме процесс, который возвращает через функцию обратного вызова промежуточные результаты своего выполнения.

Для облегчения реализации класса исполнителя в библиотеке ActiveSession есть предназначенный для этого класс: RunnerBase.Этот класс реализует базовую логику взаимодействия исполнителя с остальными элементами библиотеки и имеет защищенные методы, облегчающие реализацию специфической для приложения части исполнителя. Для облегчения реализации важной разновидности исполнителей — исполнителей последовательности (они описаны в главе про исполнители дополнительной статьи) в библиотеке реализован другой базовый класс: EnumerableRunnerBase<TItem>.

Для каждого активного сеанса создается дочерний контейнер сервисов (DI-контейнер) для области действия, существующей в течение времени существования этого активного сеанса. То есть, экземпляр любого сервиса, зарегистрированного в контейнере сервисов приложения с временем жизни Scoped, полученный из контейнера, связанного с активным сеансом, существует и остается одним и тем же для всех запросов в этом сеансе все время существования этого сеанса, и поэтому может свободно использоваться связанными с сеансом исполнителями. Ссылка на контейнер сервисов активного сеанса хранится в его объекте.
В библиотеке ActiveSession определены сервисы-адаптеры, которые позволяют внедрить в класс обработчика запросов зависимость от экземпляра сервиса, получаемого из контейнера сервисов активного сеанса, а не текущего запроса.

Фабрика исполнителя — это класс, реализующий обобщенный интерфейс IRunnerFactory<TRequest,TResult> с двумя параметрами-типами. Этот интерфейс содержит единственный метод Create. Параметр-тип TRequest — это тип аргумента, который содержит данные передаваемые в исполнитель. Этот аргумент передается в метод Create этого интерфейса. Параметр-тип TResult — это тип результата для создаваемого исполнителя. Метод Create принимает упомянутый выше параметр типа TRequest с данными, передаваемыми в конструктор исполнителя, плюс ряд дополнительных параметров, используемых инфраструктурой библиотеки ActiveSession, и возвращает интерфейс IRunner<TResult> созданного исполнителя. В этой статье вопрос создания фабрик исполнителей не рассматривается.

В библиотеке ActiveSession для облегчения регистрации сервисов фабрик самописных исполнителей предусмотрены методы расширения IServiceCollection для их регистрации в контейнере сервисов. Все эти методы являются перегруженными — имеют общее имя AddActiveSession, но различаются параметрами. Описанные выше методы регистрации стандартных фабрик исполнителей на самом деле вызывают именно эти методы. Однако описание этих методов и связанных с ними классов выходит за рамки этой статьи.

Технически ссылка добавляется через механизм функций (features) и доступна обработчикам через метод расширения GetActiveSession для класса HttpContext.

Технически UseActiveSessions — это метод расширения для интерфейса IApplicationBuilder.
В более сложных его вариантах в него можно передать условие для установки ссылки на на объект активного сеанса: это либо делегат-предикат (получающий как аргумент контекст запроса и возвращающий true или false), либо строка с регулярным выражением для пути запроса. Метод UseActiveSessions, можно вызывать несколько раз. При этом обработчик инфраструктуры библиотеки ActiveSession в любом случае устанавливается только один раз, но ссылка на на объект активного сеанса устанавливается если удовлетворяется условие, переданное в любом из вызовов UseActiveSessions: предикат возвращает true или путь запроса соответствует переданному регулярному выражению. Или же — если был хотя бы раз вызван метод UseActiveSessions без параметров: считается, что его условию удовлетворяет любой запрос.

Теперь, когда вы узнали как работать с библиотекой ActiveSession, я могу рассказать подробнее про заглавную картинку к этой статье.
Это — диаграмма, которая иллюстрирует жизненный цикл исполнителя в одном из типовых вариантов его использования.
Обозначения на этой диаграмме — следующие:

• толстые линии со стрелками обозначают основной поток управления веб-приложения: взаимодействия браузера с веб-сервером, приводящие к загрузке веб-страниц и отображение загруженных веб-страниц вместе с исполнением размещенных на них сценариев; в данном примере есть две веб страницы: с одной из них (она отображена частично и подробно не рассматривается) посылается запрос POST на сервер, другая же отображает результат выполнения этого запроса, время от времени подгружая дополнительные данные, полученные исполнителем в фоновом режиме.
• линии средней толщины (тоже со стрелками) обозначают запросы сценария на веб-странице к серверу;
• тонкие линии отображают взаимодействие обработчиков запросов с библиотекой ActiveSession и, в частности, с исполнителем.
• прерывистые и пунктирные линии отображают работу исполнителя: прерывистая линия показывает исполнитель, в работающий в фоновом режиме, а пунктирная — тот же исполнитель, до начала и после завершения фоновой операции.

Жизненный цикл исполнителя в данном примере — следующий:

1. Обработчик запроса POST на сервере создает исполнитель (вызовом IActiveSession.CreateRunner), запускает его фоновый процесс и возвращает начальный результат (всё это — вызовом метода IRunner.GetRequiredAsync). Обработчик запроса формирует страницу, отображающую этот результат, и возвращает ее браузеру. Фоновый процесс исполнителя при этом продолжает выполняться на сервере, а инфраструктура библиотеки ActiveSession удерживает в своем хранилище ссылку на этот исполнитель.
2. Браузер отображает полученную страницу и выполняет размещенный на ней сценарий, подгружающий дополнительные данные.
3. Сценарий с определенным интервалом делает запросы к точке вызова API на сервере с использованием fetch().
4. Обработчик точки вызова API находит исполнитель, запрашивает у него текущий результат вместе с состоянием и отправляет их сценарию в браузере в качестве ответа.
5. Сценарий, получив ответ, изменяет содержимое страницы, чтобы отобразить полученный результат.
6. После первых двух полученных ответов сценарий обнаруживает, что исполнитель ещё выполняется, и планирует следующий запрос к точке вызова API сервера.
7. В промежутке между вторым и третьим запросом к точке вызова API фоновый процесс исполнителя завершается. Но это не приводит к переходу исполнителя в конечную стадию, потому что исполнитель ещё не вернул окончательный результат.
8. При обработке третьего запроса исполнитель возвращает обработчику точки вызова API окончательный результат и переходит в завершающую стадию. Инфраструктура библиотеки ActiveSession, обнаружив завершение исполнителя, удаляет ссылку на него из хранилища. Теперь объект исполнителя может быть утилизирован сборщиком мусора.
9. Получив третий ответ сценарий после отображения результата обнаруживает, что исполнитель завершился и перестает делать периодические запросы к точке вызова API сервера.

Я люблю порассуждать сам и посмотреть, что пишут другие на тему, как надо и как не надо писать программы. И имею на это свое мнение. А мнение, я считаю, должно быть основано на чем-то, а именно — на фактах и на опыте. И в какой-то момент я понял, что я не знаю, во что это реально обходятся на практике все эти советы теоретиков, как правильно писать программы, именно в наше время. Мой опыт двадцати-тридцатилетней давности мало что мог подсказать, во что это "правильно" выливается, с одной стороны, при следовании модным теоретическими веяниям, а, с другой — при использовании современных средств разработки. А более свежего опыта у меня не было: мои профессиональные интересы с тех пор сместились от разработки в другую сферу.

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

Конечно, я время от времени делал всякие мелкие программки, но я хорошо осознавал, что нужного понимания на их основе не получить. На маленьких учебных примерах новых технологий и новых веяний можно только понять, как всем этим пользоваться, но — не насколько это помогает/во что все это обходится: компенсируют ли повысившиеся возможности средств разработки излишние затруднения, вносимые этими самыми новыми веяниями. Поэтому для понимания мне понадобился достаточно большой проект. А поскольку программист я не настоящий и не имею возможности заняться таким делом за счет работодателя — т.е. убедить его начать новый большой проект, причем, по сути — ради моего любопытства — то у меня остался только один выход — заняться самодеятельностью (нынче это называется "pet project"). Благо это занятие требует всего лишь времени, которого у меня, к счастью, хватает. Ну, и компьютера — но с этим сложностей сейчас нет.

Точнее — статей было две, вот вторая. Проблема, которую взялся решать автор этих статей, по моему опыту, отнюдь не была несуществующей: я сам в своей практике видел достаточно любителей запросить всё ("огласите весь список, пожалуйста"©, ага), а потом медитативно это всё просматривать, ища нужное глазами, ещё в те времена, когда программировал на Delphi. Для программ на Delphi(+BDE) такой стиль работы был терпим, хоть и не всегда (например, с MS SQL Server с его блокировками так работать не стоило, а вот с Interbase, с его многоверсионной системой хранения — запросто). Потому обеспечение такой схемы работы с веб-приложением — выбрать начальную часть данных, а остальное получать и возвращать в фоновом режиме в ответах на дополнительные запросы выглядело вполне разумным, хотя и далеким от нынешней моды решением.

А ещё при чтении этой статьи я обратил внимание на явный минимализм решения: все в нем было сделано из подручного материала, по принципу "я тебя слепила из того, что было". Это никоим образом не упрек автору — статьи были не про теорию, а про реальную жизнь а в реальной жизни обычно именно так и приходится работать: использовать то, что есть под руками. Но я уже тогда сразу подумал, что неплохо было бы допилить эту идею до полноценной библиотеки, с развесистой, по современной моде, архитектурой и использованием дополнительных возможностей ASP.NET Core из тех, что не особенно рекламируются.

В целом, архитектуру библиотеки ActiveSession я в этой, обзорной, статье решил не описывать — ибо нельзя объять необъятное.Однако какие-то слова про нее и про отличие ее от архитектуры из статьи, породившей идею, написать хотелось. И как компромисс, я про архитектуру некоторое количество слов написал, но эти слова погребены здесь, в скрытом тексте, так что мешать обзору они не будут.

Если оценивать из общих соображений, решение для хранения состояния активного сеанса — включающего в себя несколько запросов, при том, что в рамках сеанса может выполняться активный код между запросами — должно иметь определенный набор функций. Основные из них:

• привязка каждого приходящего запроса к объекту сеанса — существующему или вновь созданному;
• хранение между запросами ссылки на объект состояния сеанса и на объекты, которые выполняются в рамках сеанса в фоне, дабы они не стали добычей сборщика мусора;
• предоставление доступа к объекту сеанса обработчикам входящих в него запросов;
• возможность запуска нового кода в сеансе и взаимодействия с ранее запущенным кодом;
• своевременное освобождение объектов — объекта самого сеанса и других связанных с ним объектов — очистка их (вызовом методов Dispose/DisposeAsync, если они реализуют соответствующие интерфейсы) и удаление ссылок на них;
• с учетом того, насколько широко в ASP.NET Core используются сервисы и внедрение зависимостей от них — иметь в сеансе свой контейнер сервисов для области действия, связанной с этим сеансом.

В библиотеке из статьи решение этих задач строилось вокруг контейнера сервисов. Для каждого сеанса создавался дочерний контейнер сервисов для области сеанса. Получал объекта сеанса и связывал его с запросом добавленный в конвейер объект-обработчик (middleware). Привязка запроса выполнялась на основе переданного в нем значения куки — идентификатора сеанса. Связь запроса с сеансом устанавливалась через специальный сервис, интерфейс которого позволял получить доступ к контейнеру сервисов сеанса. Этот сервис имел время жизни области запроса, а реализация его интерфейса для этого запроса настраивалась упомянутым выше компонентом-обработчиком middleware. По замыслу библиотеки из статьи, объект, содержащий специфичные для сеанса данные, и методы, выполняемые в сеансе между запросами, регистрировался в приложении как сервис с временем жизни ограниченной области. Обработчик запроса должен был получать ссылку на этот, общий для всего сеанса, объект из контейнера сервисов, связанного с сеансом. Объект сеанса (в простейшем варианте, на момент публикации статьи, это был просто дочерний контейнер сервисов для области сеанса) помешался в стандартную реализацию кэша, доступную через общий для приложения сервис IMemoryCache под ключом сеанса, передаваемым через куки. Кэш автоматически отслеживал заданное допустимое время существования сеанса. Очистка сеанса производилась функцией обратного вызова, срабатывающей при удалении объекта из кэша. При этом вызывалась очистка дочернего контейнера кэша области сеанса, что автоматически приводило к очистке всех связанных с сеансом объектов-сервисов и удалению ссылок на них.

Короче, у автора статьи получилась весьма логичная и компактная по объему кода структура библиотеки, активно использующая при этом встроенные возможности ASP.NET Core. Но этот минимализм имел и оборотную сторону. Например, реализуя объект с кодом, выполняющимся в сеансе, как сервис, приходится отказываться от возможности легко и просто запустить в сеансе несколько экземпляров таких объектов с разными параметрами. Запустить и выполнять одновременно несколько фоновых операций можно, только если они выполняются разными сервисами. Но при этом затруднено раздельное управление этими фоновыми операциями. Например, поскольку жизненный цикл всех объектов, реализующих сервисы — когда их создавать, как долго хранить ссылку на них и когда выполнить очистку — определяется контейнером сервисов, то если одна из одновременных фоновых операций завершится, то невозможно создать новый объект того же типа, чтобы запустить с его помощью новую такую же операцию. В общем, гибкость решения была разменяна на его простоту.

Я в разработке своей библиотеки ActiveSession ограничениями по простоте реализации и объему кода связан не был (скорее, наоборот, см. выше). Поэтому я позволил себе принимать решения в интересах универсальности и гибкости.

Прежде всего, объект библиотеки ActiveSession, выполняющий код в рамках активного сеанса, больше не является сервисом, регистрируемым в контейнере сервисов, а потому не скован ограничениями, налагаемыми контейнером. Это позволило избавиться от описанных выше ограничений: один экземпляр объекта на сеанс, невозможность независимого управления выполняющими код объектами и пр. Таким образом, появилась концепция исполнителей, реализующих вновь разработанный интерфейс IRunner (он описан в статье — здесь и далее под словами "в статье" имеется виду и эта, и дополнительная статья).

Для взаимодействия объекта сеанса библиотеки ActiveSession с такой новой реализацией выполняющих код в сеансе объектов — исполнителей, вместо интерфейса контейнера сервисов (IServiceProvider) был разработан новый интерфейс, IActiveSession, (он тоже описан в статье), дающий больше возможностей возможностей, и создан реализующий его объект инфраструктуры.

Для доступа к объекту сеанса из обработчиков запросов был использован стандартный для ASP.NET Core, но при этом не особо известный механизм расширения контекста запроса (HttpContext) — механизм функций (Features). Этот механизм позволяет хранить в контексте запроса в специальной коллекции функций — свойстве Features — набор произвольных интерфейсов для реализующих эти функции объектов и извлекать их по ключу — типу интерфейса. Компонент-обработчик конвейера обработки запроса (middleware) добавляет в коллекцию функций контекста объект, реализующий интерфейс IActiveSessionFeature. Свойство ActiveSession этого интерфейса предоставляет ссылку на объект сеанса. Обработчики запросов могут получать ссылку на объект активного сеанса вызовом функции расширения GetActiveSession() для контекста запроса: он находит в коллекции функций интерфейс IActiveSessionFeature и возвращает значение его свойства ActiveSession. Объект, реализующий интерфейс функции создается обращением компонента обработчика к хранилищу ( о нем будет чуть позже). Хранилище находит существующий или создает новый объект активного сеанса и создает реализующий интерфейс функции объект, который описанным выше образом возвращает ссылку на объект этого активного сеанса.

Для привязки запросов к активному сеансу было решено не повторять свой велосипед на основе куки, как было сделано в исходной в статье, а использовать стандартный механизм сеансов ASP.NET Core, предоставляющий интерфейс ISession. механизм этот, конечно, работает через те же самые куки, но он имеет при этом дополнительные возможности. Во-первых, сеанс ASP.NET Core позволяет хранить в своей инфраструктуре дополнительные статические данные (вообще говоря — любого типа, сериализуемого в массив байтов, при этом для хранения чисел и строк есть встроенная поддержка в виде методов расширения). Во-вторых, сеансы в ASP.NET Core, в принципе, являются распределенными: если приложение выполняется параллельно на нескольких узлах, то можно настроить механизм сеансов так, чтобы на всех этих узлах данные сеанса ASP.NET Core были одинаково доступны.

Первая возможность — сохранять дополнительные данные — инфраструктурой библиотеки используется, но зависимость от нее не критична: при использовании своей куки вместо сеанса их эти данные можно было бы хранить в куки. Вторая возможность — распределенный сеанс — теоретически позволяет реализовать поддержку распределенного активного сеанса, но так как напрямую сам выполняющийся код в распределенный сеанс ASP.NET Core запихнуть невозможно, то эта реализация требует дополнительной работы. Эту работу я оставил на потом, для какой-нибудь следующей версии. Пока что в библиотеку ActiveSession просто в поиск существующего исполнителя добавлена проверка того, что найденный исполнитель, выполняется на другом узле, которая, в зависимости от настроек, либо выбросит исключение, либо вернет результат "исполнитель не найден".

Хотя в комментариях к исходной статье я предлагал на роль хранилища ссылок на объекты активных сеансов не кэш в памяти(общий IMemoryCache из контейнера сервисов или поддерживающий этот интерфейс отдельный объект MemoryCache), а другой стандартный механизм .NET — механизм параметров (Options pattern), но в зрелом размышлении я согласился с тем, что выбор кэша в памяти как основы хранилища был оптимальным. Потому что важной задачей хранилища является удаление устаревших объектов сеанса — а кэш в памяти специально ориентирован на решение именно этой задачи.

Хранилище в библиотеке ActiveSession — это отдельный, довольно сложный объект, а не просто кэш в памяти, доступный как сервис через контейнер. Потому что круг задач, решаемых хранилищем, в библиотеке ActiveSession гораздо шире. Во-первых, объекты исполнителей имеют свое время существования. В частности, при отсутствии обращения к ним они тоже могут стать устаревшими, причем — стать раньше, чем объект сеанса, в котором они выполняются. А потому исполнители — тоже хорошие кандидаты на хранение в кэше в памяти. Во-вторых, при удалении объекта активного сеанса из кэша все связанные с ним объекты исполнителей должны тоже быть удалены из кэша и очищены. То есть, у кода хранилища опять-таки появляется дополнительная работа. И раз уж все равно требуется достаточно сложный объект хранилища, то в него разумно и перенести код создания активных сеансов, исполнителей и других объектов библиотеки ActiveSession. Поэтому хранилище в библиотеке ActiveSession — это центральный объект инфраструктуры библиотеки, вокруг которого строится вся работа по созданию, хранению и освобождению объектов, используемых при работе с библиотекой. Но поскольку эта работа пользователю библиотеки не видна, то хранилище, как и другие объекты инфраструктуры, остались вне предмета рассмотрения данной статьи. Единственный компонент инфраструктуры, который был упомянут в статье — это фабрики исполнителей. Потому что эта часть инфраструктуры пользователю библиотеки видна: для создания нужных пользователю исполнителей он должен регистрировать в контейнере сервисов фабрики, которые их создают.

Кроме того, библиотека ActiveSession предоставляет расширенные возможности наблюдения за жизненным циклом объектов, находящихся в хранилище — активных сеансов и исполнителей: можно наблюдать как момент завершения выполнения и удаления объекта, так и момент завершения его очистки и настроить в приложении обработчики этих событий (об этом тоже написано в статье).

Потому что движение за "свободное ПО", так же, как и любое движение за свободу чего-нибудь и кого-нибудь, в лучшем случае — лицемерно, а худшем — одно из тех благих намерений, которыми, говорят, дорога в ад вымощена. Конкретно же, борьба за "свободное ПО" против "проприетарного" привела по факту к свободе для корпораций невозбранно гадить нам в мозги своей рекламой, да ещё и пользуясь для этого не ими разработанным ПО. Но это — тема совсем для другой статьи.

Причина трудности очевидна: если данные несложно реплицировать между узлами (в частности это делает реализация сеансов ASP.NET Core на базе распределенного кэша), то код исполнителя активного сеанса выполняется на конкретном узле и реплицировать его никуда нельзя. Так что, если запрос приходит на обработку на другой узел, то обработчик должен вызвать исполнитель с того самого другого узла. С одной стороны, это вполне реализуемо. Причем в простом, костыльном, варианте — не так уж и сложно: на узле, где выполняется исполнитель, создается специальная точка вызова HTTP API, принимающая запросы к исполнителю, а на узле, где выполняется обработчик, на время обработки запроса создается прокси-объект, который обращается к исполнителю через эту точку вызова.

Но этот вариант — именно, что костыльный. Во-первых, создание прокси-объекта для каждого запроса может быть накладным, поэтому желательно уже созданный прокси-объект сохранять в инфраструктуре библиотеки (в хранилище) для повторного использования и очищать его, когда необходимость в нем отпадет. Во-вторых, для общения между экземплярами серверной части приложения на разных узлах уже могут использоваться другие механизмы — очереди сообщений, шины и т.п., и было бы целесообразно для обращения к исполнителю использовать не простой такой вот "RPC over HTTP", прибитый к реализации гвоздями, а эти, уже имеющиеся механизмы транспорта. То есть, требуется усовершенствование архитектуры библиотеки: добавление абстрактного транспорта для запросов к исполнителям на других узлах, и реализация этого абстрактного транспорта для конкретных механизмов (хотя бы части их). Таким образом, потребуется дополнительная работа по усовершенствованию библиотеки. Может быть, когда нибудь, эта работа будет проделана, а пока что имеем это ограничение. Впрочем, интерфейсная часть библиотеки уже позволяет писать приложение так, будто его исполнители реально работают на других узлах: для этого для интерфейса IRunner уже предусмотрены методы расширения, формально выполняющие запросы к исполнителю асинхронно (что требуется для работы с исполнителем на удаленном узле через некий транспорт).

В приложении ASP.NET Core эти сервисы регистрируются как имеющие время жизни области действия (Scoped). При штатном использовании их в обработчиках запросов HTTP, с каждым из которых связана своя область действия, для каждого запроса создается свой экземпляр сервиса, который очищается по завершении обработки запроса. Таким образом параллельный доступ к одному экземпляру невозможен (по крайней мере, его несложно избежать, если не делать ошибок).

Используемый в исполнителях экземпляр контекста EF получается из контейнера сервисов активного сеанса, а потому невозможность параллельного доступа к нему в текущей версии сама по себе не гарантируется: в активном сеансе могут выполняться параллельно несколько запросов. Поэтому приложение должно использовать объекты взаимоисключающего доступа для работы с контекстами EF. Ну, или самому как-то следить за этим.

Впрочем, для предотвращения проблем конкретно с контекстами EF можно использовать средство, предназначенное в EF именно для таких случаев: фабрику контекстов — зарегистрировать в контейнере сервисов именно фабрику и получать контексты через нее. А освободить полученный от фабрики контекст можно по завершении исполнителя — как это можно сделать, рассмотрено в той же дополнительной статье.

… и я одно такое даже видел. Был у меня кусок кода размером под три сотни строк, написанный в один присест. Причем — кода непростого: там нужно было вырезать из строки подстроку не совсем простой структуры, причем — не пользуясь регулярными выражениями и прочими замечательными средствами, упрощающими и ускоряющими работу. Потому что эти средства любят выделять себе немного памяти почем зря, а потом сборщик мусора устает прибирать за ними. Короче — только StringBuilder и только простые методы поиска, вроде IndexOf. Просчитаться на единицу в таком коде — раз плюнуть. Вообще-то, в самом по себе решении этой задачи ничего чудесного не было, чудо там было другое: этот код заработал правильно с первого раза, и сколько я потом ни искал в нем ошибку (а я искал, и долго — потому что ее отсутствие было бы чудом, а я на чудеса полагаться опасаюсь) — не нашел. Так что, чудеса бывают, убедился.

Тесты — дело формальное. Их написание порождает материальные следы ("артефакты"). Тогда как проверка может проводиться даже просто заданием значений в отладчике, делаться совершенно неформально и следы она за собой оставлять не обязана. Тестирование имеет метрики, которые менеджер может измерить и даже записать их в KPI программистам. Короче, если по жизни, то проверка — это для себя и для дела, чтобы было нормально, а тесты — для менеджеров, чтобы они могли принести их жертву богу управляемости, которому они поклоняются. Объем проверки определяет сам программист на основании своего опыта, а покрытие тестами — менеджеры, согласно заветов своих менеджерских богов и пророков.

Потому что библиотека — не приложение, ее просто так на выполнение не запустишь. И потому раньше надо было для проверки и отладки чего-нибудь в библиотеке делать вспомогательное приложение, которое это что-нибудь использовало способом, нужным для проверки, и это приложение проверялось и, при необходимости, отлаживалось. А при наличии инфраструктуры тестирования можно вместо этого приложения использовать тесты: инфраструктура тестирования позволяет весьма удобно запускать куски кода библиотеки прямо в Visual Studio, в том числе — и под отладчиком. Так что, внезапно, средство для менеджеров оказалось пригодным и для программиста. В результате я с некоторого момента забросил пробное приложение (но оно осталось в репозитории с примерами) и для проверки и отладки перешел исключительно на инфраструктуру тестирования Visual Studio. Оборотной стороной такого перехода, однако, стало то, что тесты делались для потребностей проверки конкретной реализации и потому оказались сильно привязанными к этой реализации, т.е. приобрели излишнюю хрупкость. А ещё при таком процессе проверки оказалось, что громадное большинство найденных ошибок составляли ошибки в самих тестах, а не в коде библиотеки.

Согласно средствам анализа кода Visual Studio, на 2060 строк кода библиотеки у меня пришлось 5651 строк кода тестового проекта — т.е. в два с лишним раза. И это — несмотря на предпринятые меры по уменьшению дублирования в коде тестов: вынос инициализации тестов и части проверок во вспомогательные классы и методы и т.д. Правда, с другой стороны, код библиотеки оказался значительно более сложным и куда менее линейным, нежели код тестов: посчитанная Visual Studio цикломатическая сложность у проекта библиотеки оказалась, наоборот, выше почти в два раза, чем у тестового проекта: 1841 против 908. Общее количество строк в исходных файлах библиотеки тоже оказалась выше (13994 против 10556), но здесь сказался не только более плотный линейный код тестов без многочисленных строк с фигурными скобками во всяких условных операторах, циклах и пр., но и большое количество в исходном тексте библиотеки "трехслэшовых" комментариев, содержащих текст для XML-документации.

В процессе работы я начал использовать Moq и долго страдал от того, что широко известная документации него него — одна страничка с примерами. Впрочем, потом я нашел и документацию по его классам и методам — похоже, собранную какой-то программой из "трехслэшовых" комментариев в исходном тексте, и эта документация таки оказалась для меня весьма полезной — подсказки в IDE, хотя и берутся из того же источника, слишком фрагментарны, чтобы увидеть полную картину.