Синглтон на контекст вызова (веб-запрос) в Unity

Несколько дней назад у меня была эта проблема с многопоточностью ASP.Net. Я хотел иметь одноэлементный объект для каждого веб-запроса. Мне действительно нужно это для моей единицы работы. Я хотел создать единицу работы для каждого веб-запроса, чтобы идентификационная карта действовала на протяжении всего запроса. Таким образом, я мог бы использовать IoC, чтобы прозрачно внедрить свой собственный IUnitOfWork в мои классы репозитория, и я мог бы использовать тот же экземпляр для запроса, а затем обновления своих сущностей.

Так как я использую Unity, я по ошибке использовал PerThreadLifeTimeManager. Вскоре я понял, что модель потоков ASP.Net не поддерживает то, что я хочу достичь. В основном он использует theadpool и перерабатывает потоки, а это значит, что я получаю один UnitOfWork на поток!! Однако, то, что я хотел, было одной единицей работы за веб-запрос.

Немного поиска в Google дал мне этот великий пост. Это было именно то, что я хотел; за исключением части единства, которую было довольно легко достичь.

Это моя реализация PerCallContextLifeTimeManager для единства:

public class PerCallContextLifeTimeManager : LifetimeManager
{
    private const string Key = "SingletonPerCallContext";

    public override object GetValue()
    {
        return CallContext.GetData(Key);
    }

    public override void SetValue(object newValue)
    {
        CallContext.SetData(Key, newValue);
    }

    public override void RemoveValue()
    {
    }
}

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

unityContainer
            .RegisterType<IUnitOfWork, MyDataContext>(
            new PerCallContextLifeTimeManager(),
            new InjectionConstructor());

Надеюсь, это сэкономит кому-то немного времени.

Источник

3 ответа

Решение

Удобное решение, но каждый экземпляр LifetimeManager должен использовать уникальный ключ, а не константу:

private string _key = string.Format("PerCallContextLifeTimeManager_{0}", Guid.NewGuid());

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

Также стоит реализовать RemoveValue для обеспечения очистки объектов:

public override void RemoveValue()
{
     CallContext.FreeNamedDataSlot(_key);
}
Источник

Хотя это нормально, вызывая этот PerCallContextLifeTimeManager, я почти уверен, что это "небезопасно", чтобы считаться ASP.Net Per-request LifeTimeManager.

Если ASP.Net выполняет обмен потоками, то единственное, что передается новому потоку через CallContext, - это текущий HttpContext - все, что вы храните в CallContext, исчезнет. Это означает, что при большой нагрузке приведенный выше код может привести к непредвиденным результатам - и я полагаю, было бы очень сложно отследить, почему!

Единственный "безопасный" способ сделать это с помощью HttpContext.Current.Items или сделать что-то вроде:

public class PerCallContextOrRequestLifeTimeManager : LifetimeManager
{
    private string _key = string.Format("PerCallContextOrRequestLifeTimeManager_{0}", Guid.NewGuid());

    public override object GetValue()
    {
      if(HttpContext.Current != null)
        return GetFromHttpContext();
      else
        return GetFromCallContext();
    }

    public override void SetValue(object newValue)
    {
      if(HttpContext.Current != null)
        return SetInHttpContext();
      else
        return SetInCallContext();
    }

    public override void RemoveValue()
    {
    }
}

Это, очевидно, означает получение зависимостей от System.Web:-(

Более подробная информация об этом доступна по адресу:

http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html

Источник

Спасибо за ваш вклад,

Но у предложенного вопроса реализации есть два недостатка, один из которых является серьезной ошибкой, о чем уже заявили Стивен Роббинс в своем ответе и Мика Золту в комментарии.

  1. Контекст вызова не гарантируется для asp.net для одного запроса. Под нагрузкой он может переключиться на другой, что приведет к разрыву предлагаемой реализации.
  2. Он не обрабатывает освобождение зависимостей в конце запроса.

В настоящее время пакет Unity.Mvc Nuget поставляет PerRequestLifetimeManager для выполнения работы. Не забудьте зарегистрировать его связанный UnityPerRequestHttpModule в загрузочном коде, иначе освобождение зависимостей также не будет обрабатываться.

Использование начальной загрузки

DynamicModuleUtility.RegisterModule(typeof(UnityPerRequestHttpModule));

или в web.config system.webServer/modules

<add name="UnityPerRequestHttpModule" type="Microsoft.Practices.Unity.Mvc.UnityPerRequestHttpModule, Microsoft.Practices.Unity.Mvc" preCondition="managedHandler" />

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

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

Источник
Другие вопросы по тегам