2016-03-09 5 views
0

У меня есть это устаревшее ASP.NET webapp, которое в основном перешло на MVC. Проверка кода, как правило, плохая, так как это часто случается с устаревшими приложениями: ответственность лежит в беспорядке, преобладает жесткая связь, такая вещь.Неправильно ли создать HttpContextProvider для использования в IHttpModules?

Я занимаюсь реорганизацией приложения на пару недель, чтобы улучшить тестируемость, делая все возможное, чтобы соблюдать SOLID, и я пришел к этому моменту, когда мне нужно передать HttpContext или HttpResponse и тому подобное методу в HttpModule. Теперь, очевидно, HttpModules может захватить копию HttpApplication и просто передать это везде - то есть как это atm - но я предпочел бы не предоставлять доступ к столь большому корневому объекту к зависимости.

Поскольку некоторые из наших IHttpModules инициализируются перед MVC даже входит в игру, у меня были проблемы с использованием контейнера IoC, чтобы ввести HttpContextBase или HttpResponseBase в конструкторах различных помощников, которые используют модули. Таким образом, я должен либо передать HttpContextBase методам указанных хелперов - который взимание налогов использовать и чувствует себя несколько неправильно - или создать что-то вроде этого:

public class HttpContextProvider : IHttpContextProvider { 
    // ... ctor 
    public HttpContextBase GetContext() { return HttpContext.Current; } 
} 

Я бы тогда впрыснуть экземпляр, реализующий IHttpContextProvider в качестве помощника и вызова .GetContext() на нем позже по мере необходимости.

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

ответ

1

я могу предложить различные варианты

  1. попытка зарегистрировать это объекты в IoC, но чтобы решить эту проблему (этот класс инициализируется перед его зависимости могут быть решены) просто использовать Ленивый < T>, наиболее IoC поддерживать их, проверить, если у вас
  2. Вводя поставщиков, как в вашем примере, но я предлагаю ему вернуться не HttpContext (или HttpResponse), но именно то, что вам нужно от этого класса, было бы легче в тестах до m Ock это поведение (вы, возможно, даже не нужно построить контекст там вообще), а также скроет все сложные вещи из HttpContext, который не используется

Второй вариант будет работать только если вы используете каждый объект похож, так что вы можете заменить его на 2-3 метода ISmthProvider. Если вы используете объекты всегда по-другому, может быть, это будет лучше сочетать оба подхода и извлекать наиболее популярные использований в какую-то службу и в других местах пути Лазы < HttpContextBase> конструктору

На мой взгляд, лучше не пропускать HttpContext/HttpResponse непосредственно, поскольку он дает доступ к слишком большому количеству вещей, а позже люди могут сделать беспорядок (используя его, не думая, как оно уже есть), в результате было бы сложно проверить и сделать рефакторинг позже.