Контейнер для инъекций зависимостей по запросу

Question

Очень распространено создание контейнера внедрения зависимостей для приложения ASP.NET, чтобы он работал в течение всего срока службы приложения.

Я создаю контейнер DI в каждом запросе и освобождаю его в конце запроса.
Основная цель заключается в том, чтобы любой контейнер DI поддерживал удаление объектов при удалении контейнера.

---

Дополнительно: Если мне нужно разделить ресурсы между запросами (NHibernate SessionFactory), я просто храню их в статической переменной и инкапсулирую это значение в объекте для каждого запроса. Как это:

public class SessionFactoryAggregator : ISessionFactory {
    static ISessionFactory actualFactory;

    // Implement ISessionFactory and proxy calls to the actualFactory
}

Это просто симуляция одиночного паттерна.

---

Мои вопросы:

1. Это нормально делать?
2. Если нет, то почему и что вместо этого следует сделать?
3. Известны ли проблемы с производительностью при таком подходе?

---

Обновление: В настоящее время я использую Castle Windsor через свою собственную абстракцию провайдера DI, поэтому фактический контейнер является подключаемым.

Спасибо.

Answer 1

Если это работает для вас, тогда все в порядке:)

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

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

Большинство DI-контейнеров имеют возможность управлять временем жизни объекта, и большинство из них даже поддерживают веб-интерфейс, что означает, что вы должны быть в состоянии сказать ему, что определенные компоненты имеют время жизни "на запрос" и что они должны распоряжаться после каждого запроса.

Это позволит вам поддерживать другие компоненты в качестве синглетонов (шаблон времени жизни, а не шаблон создания), чтобы их можно было использовать для нескольких запросов. Это часто может быть хорошей идеей для компонентов доступа к данным, которые, как правило, являются поточно-ориентированными, так как не содержат изменяемого состояния.