Какие знаешь времена жизни объектов в IoC контейнере кроме singleton?

Основные времена жизни объектов в IoC контейнере

Помимо singleton, который создаёт единственный экземпляр на весь жизненный цикл приложения, существует несколько других важных времен жизни объектов, каждый из которых решает определённые проблемы и оптимизирует работу приложения.

Transient (Временный)

Это самое короткое и распространённое время жизни. Transient означает, что каждый новый запрос на получение объекта из контейнера приводит к созданию нового экземпляра.

// Регистрация в .NET Core DI
services.AddTransient<IMyService, MyService>();

Применение и особенности:

• Идеально для служб без состояния, которые выполняют конкретные операции (например, валидаторы, преобразователи данных).
• Не подходит для объектов, которые требуют значительных ресурсов для создания или имеют длительное состояние.
• Потенциальная проблема: при частых запросах может привести к большому количеству созданных объектов и увеличению нагрузки на память.

Scoped (Скоуп / Область действия)

Scoped — один из самых практичных подходов. Контейнер создаёт один экземпляр объекта на протяжении определённой области (scope), например, на один HTTP запрос в веб-приложении.

// Регистрация в ASP.NET Core
services.AddScoped<IDatabaseContext, DatabaseContext>();

Ключевые моменты:

• В рамках одного HTTP запроса все компоненты, зависящие от IDatabaseContext, получают один и тот же экземпляр, что обеспечивает корректную работу с транзакциями или единым состоянием.
• После завершения запроса объект уничтожается (если не реализован как IDisposable, то память освобождается при сборке мусора).
• Очень важно для работы с Entity Framework Core и другими ORM, где контекст должен быть единым на транзакцию.

Instance (Предварительно созданный экземпляр)

Это подход, когда вы создаёте экземпляр самостоятельно и регистрируете его в контейнере. Контейнер затем всегда возвращает этот конкретный экземпляр.

var myInstance = new MyService(config);
services.AddSingleton<IMyService>(myInstance);
// Или для других времен жизни, если требуется контроль
services.AddScoped<IMyService>(provider => myInstance);

Плюсы и минусы:

• Полный контроль над процессом создания и инициализации объекта.
• Полезно для сложных объектов, которые требуют особой конфигурации вне контейнера.
• Может затруднить управление жизненным циклом, если объект реализует IDisposable.

Per Thread (На поток)

Не является стандартной регистрацией в большинстве контейнеров (например, встроенный DI .NET Core не поддерживает напрямую), но реализуется в некоторых сторонних библиотеках (Autofac, Ninject) или через кастомные решения.

// Пример реализации в Autofac
builder.RegisterType<MyService>().InstancePerThread();

Специфика:

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

Per Request (На запрос) в веб-контексте

Часто является синонимом Scoped в веб-приложениях, но в некоторых фреймворках или контейнерах может иметь отдельную семантику (например, в Autofac для MVC).

Сравнение и выбор времени жизни

Выбор времени жизни зависит от нескольких факторов:

Рекомендации по выбору:

• Singleton: для служб конфигурации, логгеров, кэшей, фабрик — объектов, которые должны быть едиными и долговременными.
• Scoped: для работы с базой данных (DbContext), единиц работы (Unit of Work), объектов с состоянием на один запрос.
• Transient: для лёгких служб без состояния, которые выполняют отдельные задачи (сервисы расчета, валидации).
• Instance / Per Thread: для специфичных случаев, где требуется тонкий контроль или многопоточная оптимизация.

Опасности и типичные ошибки:

• Вложение Scoped службы в Singleton может привести к неправильному управлению памятью (Scoped объект может жить неожиданно долго).
• Использование Transient для тяжелых объектов (с большим конструктором или внешними зависимостями) может снизить производительность.
• Неправильная регистрация времени жизни для IDisposable объектов может вызвать утечки ресурсов (например, не закрытые соединения с БД).

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