DI-контейнер: что он делает вместо вас — и чем dishka отличается от dependency-injector

Зачем вообще контейнер

Без него сборка объекта расползается по обработчикам:

def handler(request):
    session = Session(pool)
    users = UserRepo(session)
    orders = OrderRepo(session)
    try:
        return UnitOfWork(users, orders).run(request)
    finally:
        session.close()

Три строки из семи только создают объекты. Добавьте зависимость в UnitOfWork — и править придётся каждый обработчик.

Но посмотрите на session внимательнее. Она одна на оба репозитория и закрывается на выходе. Оба свойства — не про сборку, а про время жизни. С этого места библиотеки и начинают отвечать по-разному.

Главное различие

dishka знает, что такое запрос. Вы объявляете, что сессия живёт в Scope.REQUEST, и внутри одного запроса она одна на всех, кто её попросил, а на выходе закрывается сама.

dependency-injector этого понятия не имеет. Его Factory честно предупреждает в документации, что создаёт новый объект на каждый запрос зависимости, — и создаёт: UserRepo получил одну сессию, OrderRepo вторую.

Если нужна одна сессия на запрос — есть ContextLocalSingleton. Но границу запроса тогда проводите вы:

try:
    return container.uow()
finally:
    container.session.reset()      # забудете — сессия переживёт запрос

И самое неприятное: без этой строки один запрос выглядит правильным. Ошибка видна только со второго.

Когда узнаёшь, что всё собрано неправильно

• dishka проверяет весь граф при создании контейнера. Нет фабрики для зависимости — падение на старте приложения, где его увидит и CI.
• dependency-injector создаёт контейнер молча. Ошибка приходит при первом вызове, и приходит в виде TypeError из вашего же класса.
• А если забыть вызвать wire(), ошибки не будет вообще: в аргумент придёт служебный объект-маркер, и падение случится позже и в другом месте.

Что при этом не подтвердилось: расхожее «dependency-injector не типизирован». mypy одинаково хорошо ловит несовпадение типа результата у обеих библиотек.

Что это стоит

Сравнивать по скорости можно только одинаковую работу, и таких мест два — с противоположным результатом:

• отдать уже созданный объект: 40 нс у dependency-injector против 238 у dishka. Причина простая — его провайдеры скомпилированы (providers.abi3.so);
• сделать «одна сессия на запрос»: 2462 нс у dishka против 5583 у ContextLocalSingleton со сбросом — и в эти 2462 нс dishka ещё и закрывает сессию, а reset() только отпускает ссылку.

Всё остальное несравнимо. Factory дешевле полного запроса dishka ровно потому, что не открывает границу запроса, не закрывает сессию и выдаёт две вместо одной.

Как выбрать

Вопрос не «что быстрее», а нужна ли вам граница запроса как понятие.

Нужна, если в одном запросе больше одного потребителя общего ресурса — двух репозиториев с одной сессией уже достаточно. Тогда dishka закрывает вопрос механизмом, а не дисциплиной.

Не нужна, если контейнер у вас — реестр объектов, живущих столько же, сколько процесс: конфигурация, пул, клиенты. Тогда dependency-injector делает ровно то, что нужно, быстрее, и у него есть провайдер Configuration, читающий YAML, INI и переменные окружения.

Чего точно не стоит — выбирать по числам из README. Двести наносекунд на одном обращении за зависимостью не видны ни в одном веб-приложении. Видна другая разница: та, где две записи оказались в разных транзакциях.

Что именно делает контейнер

Термину двадцать два года, и появился он в тексте с точной датой.

Сама идея у Фаулера сформулирована через отдельный объект-сборщик:

Обратите внимание, чего в этом определении нет. Нет слов «уменьшить связанность», «упростить тестирование» и «инверсия управления» — всё это следствия, а не механизм. Механизм — сборщик, который знает, что чем заполнять.

Первая задача контейнера — собрать граф. Без него код выглядит так:

def handler(request):
    session = Session(pool)
    users = UserRepo(session)
    orders = OrderRepo(session)
    unit = UnitOfWork(users, orders)
    try:
        return unit.run(request)
    finally:
        session.close()

Почти всё тело обработчика — сборка: четыре строки из восьми только создают объекты. Добавьте ещё одну зависимость в UnitOfWork, и придётся пройти по всем обработчикам.

Вторая задача — и вот она обычно не названа. Посмотрите на session в примере: она одна на оба репозитория и закрывается в finally. Оба этих свойства — не про сборку, а про время жизни: сколько живёт объект и кто его на этом отрезке делит. Именно здесь две библиотеки расходятся, и разница дороже любой разницы в скорости.

Одна сессия на запрос — или по одной каждому

Проверка простая. Два репозитория в одном запросе, обоим нужна сессия.

dishka отвечает на этот вопрос понятием области жизни.

class MyProvider(Provider):
    pool = provide(Pool, scope=Scope.APP)
    users = provide(UserRepo, scope=Scope.REQUEST)
    orders = provide(OrderRepo, scope=Scope.REQUEST)
 
    @provide(scope=Scope.REQUEST)
    def session(self, pool: Pool) -> Iterable[Session]:
        session = Session(pool)
        yield session
        session.close()

Внутри одного REQUEST сессия одна, и это проверено сравнением по is. На выходе из области выполняется всё, что стоит после yield, — The finalization of dependencies runs in reverse creation order (Завершение зависимостей идёт в порядке, обратном созданию). Границу рисует контекстный менеджер: To enter a nested scope, you call it and use it as a context manager (Чтобы войти во вложенную область, вы вызываете контейнер и используете результат как контекстный менеджер).

dependency-injector встроенной иерархии областей не имеет — и не скрывает этого. Его основной провайдер документирован так:

Каждый раз — значит каждый раз. UserRepo попросил сессию и получил новую, OrderRepo попросил и получил ещё одну. Измерено: два разных номера сессии, users.session is orders.session даёт False. Отсюда следствие, которого замер уже не показывает: две записи одного запроса уйдут в разные транзакции, и заметно это станет на первом же откате.

Если вам нужна одна сессия на запрос, у библиотеки есть для этого ContextLocalSingleton: сессия становится одной на контекст выполнения. Но границу запроса вы теперь проводите сами:

try:
    return container.uow()
finally:
    container.session.reset()      # без этой строки сессия переживёт запрос

Провайдер с завершением у dependency-injector всё-таки есть — Resource: Resource provider provides a component with initialization and shutdown (Провайдер Resource предоставляет компонент с инициализацией и завершением). Но его инициализация happens only once (происходит только один раз), то есть это уровень приложения, а не запроса; для запроса документация отсылает к отдельному ContextLocalResource, и границу ему по-прежнему проводите вы.

И вот здесь важное: без reset() всё выглядит правильно ровно один запрос. Сессия общая, транзакция одна, тесты зелёные. Второй запрос получает ту же самую сессию — и это видно только тогда, когда запросов становится два.

Как зависимость находят

Второе расхождение — по способу указать, что именно внедрять.

dishka ищет по аннотации типа. container.get(Service) — и всё; фабрика находится по типу, который вы объявили. То же в обработчике: параметр FromDishka[Service].

dependency-injector ищет по маркеру, указывающему на конкретный атрибут конкретного контейнера:

Разница выглядит стилистической, а даёт три практических следствия, и все три проверяются.

Первое: аннотация и маркер не сверяются. Вот код, который проходит и контейнер, и mypy:

@inject
def handler(service: Service = Provide[Container.config]) -> str:
    return service.run()

В параметр, объявленный как Service, приходит Config. Падает это позже — AttributeError: 'Config' object has no attribute 'run' — и в другом месте.

Второе: забытый wire() не даёт ошибки. Патчить нечего, значение аргумента по умолчанию остаётся прежним, и обработчик получает сам объект-маркер:

print(type(handler()).__name__)   # 'Provide'

Ни исключения, ни предупреждения. У dishka симметричный случай — необёрнутый обработчик — падает сразу: TypeError: missing 1 required positional argument.

Третье: зависимость по типу проверяема заранее. Раз фабрика ищется по аннотации, весь граф можно обойти в момент сборки контейнера — что dishka и делает.

Сколько кода придётся переписать при смене библиотеки

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

Ответ у обеих начинается одинаково, и это стоит сказать прямо, потому что спор обычно ведут не о том. Прикладной слой не трогает ни одна. dishka формулирует это требованием к самой себе:

Третий пункт — не оговорка, а честно названная зона присутствия: границы областей. dependency-injector обещает то же про структуру приложения и адресует маркеры туда же:

Значит, вопрос не «сколько кода заражено», а «что именно называет маркер в адаптерном слое».

И вот тут расхождение принципиальное. Форма у маркеров одинаковая — оба Annotated: FromDishka[Service] есть Annotated[Service, FromComponent()], а у dependency-injector поддержан Annotated[Service, Provide[Container.service]]. Разное — содержимое. Первый называет тип. Второй — путь к атрибуту конкретного контейнера.

Отсюда цена переезда:

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

Есть и вещь, которой у dishka нет вовсе: список файлов с маркерами. У dependency-injector он существует явно, потому что подключение делается вызовом:

container.wire(modules=["yourapp.module1", "yourapp.module2"])

Это одновременно и неудобство (список надо вести), и то, чего не хватает второй библиотеке: границу заражения видно в одном месте, и её можно посчитать. Считать при выборе стоит именно это — число файлов в wire() против числа файлов, где стоит FromDishka[].

Способы ослабить связь у обеих документированы, но не бесплатны. У dependency-injector есть строковые идентификаторы: With string identifiers you don't need to use a container to specify an injection (Со строковыми идентификаторами вам не нужен контейнер, чтобы указать внедрение). Импорт контейнера из прикладного модуля уходит — а проверка типа слабеет ещё сильнее, чем в разобранном выше случае.

У dishka есть DishkaRoute, снимающий @inject, но не FromDishka[]: автоматическое внедрение работает only for HTTP, not for websockets (только для HTTP, не для веб-сокетов), а сам маркер параметра остаётся обязательным. Убрать и его можно — в исходнике default_parse_dependency голая аннотация типа возвращает None, то есть по умолчанию не внедряется, но параметр parse_dependency у wrap_injection публичный, и своя интеграция вправе внедрять по типу. Ценой своей интеграции.

Итог, который стоит унести: отчуждаем у обеих не прикладной слой — он отчуждаем изначально, — а адаптерный. И вопрос при выборе один: маркер называет ваш тип или их контейнер.

Когда становится известно, что всё собрано неправильно

Это свойство замечают последним и платят за него больше всего.

Разница в одну строку кода:

container = make_container(MyProvider())
# dishka: GraphMissingFactoryError — прямо здесь, на старте приложения
 
container = MyContainer()
# dependency-injector: контейнер создан; TypeError придёт при первом вызове

У dependency-injector есть check_dependencies(), и она хорошая: находит незаданную зависимость с понятным текстом. Но вызвать её нужно самому, и покрывает она только объявленные providers.Dependency — забытый аргумент конструктора в неё не попадает.

Про типизацию — вопреки ожиданию. Утверждение «dishka типобезопасна, а dependency-injector нет» проверялось прогоном mypy и не подтвердилось: container.get(Service) и container.service() оба возвращают Service, и присваивание результата переменной другого типа mypy ловит в обоих случаях. Не ловит он ровно одно — подмену внутри Provide[...], потому что маркер с аннотацией не сверяется ничем.

Симметричный случай у dishka тоже есть: запрос REQUEST-зависимости на APP-уровне даёт NoFactoryError с указанием области — понятно, но уже во время выполнения, а не в make_container. У dependency-injector такой ошибки быть не может: объявленной области, которую можно перепутать, в нём нет — границу вы проводите сами.

Что это стоит

Сравнивать эти библиотеки по скорости можно только там, где они делают одно и то же, — и таких мест два.

Отдать уже созданный объект. Здесь dependency-injector быстрее в шесть раз: 40 нс против 238. Причина видна одной строкой:

from dependency_injector import providers
print(providers.__file__)     # .../providers.abi3.so

Это скомпилированный модуль. dishka — чистый Python.

Сделать «одна сессия на запрос». А здесь порядок обратный: 2462 нс у dishka против 5583 нс у ContextLocalSingleton со сбросом. В 2,3 раза — в пользу нескомпилированной библиотеки, потому что скомпилированной приходится делать эту работу окольным путём. Оговорка та же, что абзацем ниже, только в другую сторону: в свои 2462 нс dishka ещё и закрывает сессию, а reset() только отпускает ссылку. То есть медленнее здесь тот, кто делает меньше.

Всё остальное в замере сравнивать между собой нельзя. Factory собирает граф за 1840 нс против 2462 у dishka — и не открывает границу запроса, не закрывает сессию и выдаёт две вместо одной. «Быстрее» здесь означает «сделал меньше».

Отдельно стоит цена самой границы: вход и выход из области без единого resolve стоят 785 нс из 2462. То есть почти треть цены запроса — это не сборка графа, а его время жизни.

И цена старта: make_container — 969 мкс против 170 мкс у DeclarativeContainer. На запуске приложения это не значит ничего; в наборе тестов, где контейнер создаётся на каждый тест, значит. Покупается на неё проверка графа целиком.

Как выбирать

Вопрос не в скорости — числа выше показывают, что ответ на него зависит от того, что ваше приложение делает чаще. Вопрос в том, нужна ли вам граница запроса как понятие языка.

Она нужна, если в одном запросе больше одного потребителя общего ресурса: двух репозиториев с одной сессией достаточно, чтобы Factory стал источником тихих ошибок, а ContextLocalSingleton — источником обязанности не забыть reset() в каждой ветке. Тогда dishka закрывает вопрос механизмом, а не дисциплиной.

Она не нужна, если контейнер у вас — реестр синглтонов: конфигурация, пул, клиенты внешних служб, всё живёт столько же, сколько процесс. Тогда dependency-injector делает ровно то, что нужно, и делает это быстрее — плюс у него есть провайдер Configuration, читающий YAML, INI и переменные окружения.

Чего не стоит делать в обоих случаях — выбирать по бенчмаркам из README. Разница в 200 наносекунд на одном обращении за зависимостью не видна ни в одном веб-приложении: на фоне одного запроса к базе это ноль. Видна другая разница — та, где две записи оказались в разных транзакциях.

История версий

Чем измерено

Числа этой статьи получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона: на чём считали, что получилось и с каким разбросом.

• bench/di/cost.py
• bench/di/graph.py