Как лучше всего реализовать жизненный цикл для каждого представления для компонентов, внедренных в IoC

Я работаю над приложением WPF, использующим архитектуру MVC и контейнер IOC. В настоящее время я борюсь с проблемой проектирования, связанной с объемом и сроком службы определенных компонентов, поставляемых с контейнером. Вот ситуация.

Я сделаю обобщение, сказав несколько неправильно, что контейнеры IOC поддерживают два жизненных цикла компонентов, одноэлементный и переходный. Но нам нужна золотая середина для определенных наборов компонентов.

Рассмотрим представление, которое отображает список записей в сетке. Когда пользователь нажимает на запись, откроется новое представление для отображения сведений о записи и возможности редактирования. У пользователя может быть открыто много таких представлений, каждое из которых отображает отдельную запись. Каждое представление также получает свою собственную модель и контроллер.

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

Помимо модели, представления и контроллера, существует множество других компонентов, для которых нам нужен один экземпляр на каждый набор mvc. Например, мы реализуем шаблон диалога NHibernate, который требует, чтобы сеанс открывался при открытии представления и оставался открытым до его закрытия. Точно так же каждому набору нужен собственный общий брокер событий и, возможно, несколько «других вещей». Если бы все эти зависимости были устранены в момент создания представления, это не было бы проблемой. Мы могли бы объявить все из них временными и покончить с этим.

Однако некоторые из этих лениво разрешенных зависимостей сами по себе имеют зависимости от модели, контроллера или «других вещей». Итак, проблема в том, что при разрешении ленивой зависимости контейнер за делегатом должен внедрить правильный экземпляр каждой зависимости. Это, конечно, подразумевает, что сам делегат каким-то образом привязан к набору mvc, но это не должно быть проблемой, если можно решить более крупную проблему.

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

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