Нулевой пользователь в HttpContext, полученный из StructureMap

Я не работал с OWIN, но при размещении в интегрированном режиме IIS HttpContext не заполняется до тех пор, пока не завершится событие HttpApplication.Start. С точки зрения DI это означает, что вы не можете полагаться на использование свойств HttpContext в любом конструкторе.

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

Чтобы обойти это, вы можете внедрить абстрактную фабрику в свою реализацию ICurrentUser и использовать шаблон Singleton для доступа к ней, что гарантирует, что HttpContext не будет доступен, пока он не будет заполнен.

public interface IHttpContextFactory
{
    HttpContextBase Create();
}

public class HttpContextFactory
    : IHttpContextFactory
{
    public virtual HttpContextBase Create()
    {
        return new HttpContextWrapper(HttpContext.Current);
    }
}

public class CurrentUser // : ICurrentUser
{
    public CurrentUser(IHttpContextFactory httpContextFactory)
    {
        // Using a guard clause ensures that if the DI container fails
        // to provide the dependency you will get an exception
        if (httpContextFactory == null) throw new ArgumentNullException("httpContextFactory");

        this.httpContextFactory = httpContextFactory;
    }

    // Using a readonly variable ensures the value can only be set in the constructor
    private readonly IHttpContextFactory httpContextFactory;
    private HttpContextBase httpContext = null;
    private Guid userId = Guid.Empty;
    private string userName = null;

    // Singleton pattern to access HTTP context at the right time
    private HttpContextBase HttpContext
    {
        get
        {
            if (this.httpContext == null)
            {
                this.httpContext = this.httpContextFactory.Create();
            }
            return this.httpContext;
        }
    }

    public Guid UserId
    {
        get
        {
            var user = this.HttpContext.User;
            if (this.userId == Guid.Empty && user != null && user.Identity.IsAuthenticated)
            {
                this.userId = user.GetIdentityId().GetValueOrDefault();
            }
            return this.userId;
        }
        set { this.userId = value; }
    }

    public string UserName
    {
        get
        {
            var user = this.HttpContext.User;
            if (this.userName == null && user != null && user.Identity.IsAuthenticated)
            {
                this.userName = user.Identity.Name;
            }
            return this.userName;
        }
        set { this.userName = value; }
    }
}

Лично я бы сделал свойства UserId и UserName доступными только для чтения, что упростило бы дизайн и гарантировало, что они не будут перехвачены где-либо еще в приложении. Я бы также создал службу IClaimsIdentityRetriever, которая внедряется в конструктор ICurrentUser вместо получения идентификатора утверждения в методе расширения. Методы расширения идут вразрез с сутью DI и, как правило, полезны только для задач, которые гарантированно не имеют никаких зависимостей (таких как манипуляции со строками или последовательностями). Слабая связанность создания службы также означает, что вы можете легко заменить или расширить реализацию.

Конечно, это подразумевает, что вы также не можете вызывать свойства UserId или UserName вашего класса CurrentUser ни в каком конструкторе. Если какой-либо другой класс зависит от ICurrentUser, вам также может понадобиться ICurrentUserFactory для его безопасного использования.

Абстрактная фабрика спасает при работе со сложными для внедрения зависимостями и решает множество проблем, включая эту.