Как получить доступ к Request.Properties за пределами Web API-контроллера

Question

Я устанавливаю свойство на Request.Properties внутри DelegatingHandler после того, как я вырву некоторые данные из заголовка входящего запроса в веб-API.

Все это работает нормально. Я также могу получить доступ к Request.Properties как внутри контроллера, так и в моих фильтрах «Действие» и «Исключение». Однако мне также необходимо получить доступ к этим данным из-за пределов контроллера (я называю класс бизнес-уровня с контроллера). Это данные, которые я хочу включить в некоторые журналы в других местах,

Я могу видеть HttpContext.Current из этого класса, и я могу видеть исходный заголовок отсюда, поэтому, я думаю, я мог бы вырвать его снова, но поскольку у меня есть уже сделал это и поместил его в Свойства, кажется, имеет смысл получить его оттуда. Однако, похоже, у меня нет доступа к Request.Properties из другого места.

Если это неправильный способ сделать это, как еще я могу обойти эти данные для каждого запроса, чтобы он был доступен из любой точки стека в веб-API?

Answer 1

Мне также нужно получить доступ к [Request.Properties] данным из-за пределов контроллера (я называю класс бизнес-уровня с контроллера). Это данные, которые я хочу включить в некоторые журналы в других местах ... Однако у меня нет доступа к Request.Properties из любого места. Если это неправильный способ сделать это, как еще я могу передать данные для каждого запроса, чтобы он был доступен из любой точки стека в веб-API?

Вы можете получить его от HttpContext.Current, хотя он не идеален. Имейте в виду, что если любые другие не-веб-приложения потребляют один и тот же бизнес-уровень, то HttpContext.Current будет null. HttpContext.Current только не является нулевым, когда вы работаете в IIS, а поток IIS обрабатывает выполнение стека запросов. Если вы когда-либо планируете самостоятельно размещать веб-api, используя OWIN без IIS, не будет HttpContext.Current.

Лично, если данные действительно является достаточно важным, чтобы быть переданы в бизнес-слой, чтобы быть зарегистрированным, то я бы просто передать его в метод бизнес-слоя:

public Task<HttpResponseMessage> SomeAction(SomeModel model) { 
    ... other code 
    someBusinessLayerObject.SomeMethod(arg1, arg2, Request.Properties["myHeaderKey"]); 
} 

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

Третий вариант, если вы используете инверсию управляющего контейнера, заключался бы в том, чтобы добавить какой-то класс зависимостей объекта с областью действия и поместить туда данные. Затем конструктор вводит его в класс бизнес-уровня:

public interface IHaveRequestData { 
    IDictionary<string, object> Properties { get; set; } 
} 

public class RequestData : IHaveRequestData { 
    public IDictionary<string, object> Properties { get; set; } 
} 

// ioc registration pseudocode 
iocContainer.Register<IHaveRequestData, RequestData>(Lifetime 
    .WhateverYouNeedSoThatOneOfTheseGetsCreatedForEachWebRequest); 

public class SomeController : ApiController { 
    private readonly IHaveRequestData RequestData; 
    public SomeController(IHaveRequestData requestData) { 
     RequestData = requestData; 
    } 

    public Task<HttpResponseMessage> SomeAction() { 
     // you may even be able to do this part in an action filter 
     RequestData.Properties = Request.Properties; 
    } 
} 

public class SomeBusinessLayerComponent { 
    private readonly IHaveRequestData RequestData; 
    private readonly ILog Log; 
    public SomeBusinessLayerComponent(IHaveRequestData requestData, ILog log) { 
     RequestData = requestData; 
     Log = log; 
    } 

    public Task SomeMethod() { 
     Log.Info(RequestData["myHeader"]); 
    } 
}