В StructureMap, как я могу изменить InstanceScope во время выполнения? - PullRequest
Новая
       6

В StructureMap, как я могу изменить InstanceScope во время выполнения?

1 голос
/ 24 мая 2009

В моем DefaultRegistry у меня есть эта конфигурация: 

ForRequestedType<INHUnitOfWork>().CacheBy(InstanceScope.HttpContext)
        .TheDefault.Is.OfConcreteType<NHibernateUnitOfWork>();

В какой-то момент в потоке веб-приложений я хочу изменить InstanceScope на HttpSession, чтобы получить длинный разговор, поэтому я делаю это: 

PluginTypeConfiguration config = ObjectFactory.Model.PluginTypes.FirstOrDefault(p => p.PluginType.FullName.Contains("INHUnitOfWork"));
config.Lifecycle.EjectAll();
config.Lifecycle = StructureMap.Pipeline.Lifecycles.GetLifecycle(InstanceScope.HttpSession);

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

Позже я также хочу иметь возможность отменить изменения следующим образом: 

PluginTypeConfiguration config = ObjectFactory.Model.PluginTypes.FirstOrDefault(p => p.PluginType.FullName.Contains("INHUnitOfWork"));
config.Lifecycle.EjectAll();
config.Lifecycle = StructureMap.Pipeline.Lifecycles.GetLifecycle(InstanceScope.HttpContext);

но если я заставлю его работать в одном направлении, он, вероятно, будет работать в обоих направлениях.

Можно ли заменить начальный InstanceScope навсегда во время выполнения? Как это должно быть реализовано? Кроме того, считаете ли вы, что это хороший способ получить длинную беседу или есть лучший / более простой способ сделать это с помощью StructureMap & NHibernate?

Ответы [ 2 ]

1 голос
/ 24 мая 2009

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

http://ayende.com/Wiki/Default.aspx?Page=HttpModules&AspxAutoDetectCookieSupport=1

Я бы порекомендовал создать модуль UnitOfWorkApplication и сделать его ответственным за создание экземпляра UnitOfWork и добавление его в контейнер до выполнения вашего кода (до обработки запроса, как в примере). Таким образом, у вас будет больше гибкости и контроль над тем, как создается единица работы.

0 голосов
/ 24 мая 2009

Для меня звучит немного странно, что вы пытаетесь сделать. Маршруты, которые я бы попробовал, были бы

  • Сконфигурируйте именованный экземпляр в StructureMap, который также реализует указанный интерфейс, но имеет другие области. Вы можете ввести разные зависимости для разных потребителей интерфейса, может, это поможет?
  • Напишите свой собственный CacheInterceptor, который эффективно реализует ваш конкретный жизненный цикл.

Последнее делается, например, здесь для жизненного цикла WCF: http://blogs.rpionline.com/post/2009/02/How-to-use-NHibernate-and-StructureMap-in-a-WCF-application.aspx

...