Моя команда находится в процессе разработки системы, в которой мы используем Unity в качестве нашего контейнера IoC;и для предоставления NHibernate ISessions (единиц работы) для каждого HTTP-запроса мы используем Unity функцию Unity * для создания дочернего контейнера для каждого запроса и вставляем туда ISession.
Мы пришли к этому подходу после того, как попробовали другие (включая определение времени жизни каждого запроса в контейнере, но там есть проблемы) и теперь пытаемся выбрать стратегию модульного тестирования.
Правильнотеперь сам контейнер уровня приложения находится в HttpApplication, а контейнер Request - в HttpContext.Current.Очевидно, что ни один из них не существует во время тестирования.
Боль усиливается, когда мы решили использовать расположение службы на уровне нашего домена, чтобы «лениво» разрешать зависимости от контейнера.Так что теперь у нас есть больше компонентов, которые хотят общаться с контейнером.
Мы также используем MSTest, который представляет некоторые дилеммы параллелизма во время тестирования.
Итак, мы 'Вы задаетесь вопросом, что делают умные люди в SO-сообществе, чтобы справиться с этим затруднительным положением?
Как можно настроить приложение, которое во время «реальной» среды выполнения использует объекты HTTP для хранения контейнеров, ново время тестирования имеет гибкость для последовательного наращивания и демонтажа контейнеров, и биты ServiceLocation могут получить эти точные контейнеры.
Надеюсь, вопрос ясен, спасибо!
Спасибо за ответы.Я согласен с тем, что использование Service Location не является оптимальным подходом - но в этой ситуации это действительно необходимо.Сценарий заключается в том, что нам нужны наши сущности для разрешения зависимостей, по требованию , только при необходимости - для проверки бизнес-правил.Принуждение всех наших сущностей после материализации с помощью NHibernate к инжектированию конструктора кажется неуместным, как минимум, из соображений производительности.
Мы рассматриваем решение, в котором контейнерыхранятся либо в HttpApplication / HttpContext в реальном времени, а также в статических / ThreadStatic полях во время тестирования. StructureMap имеет аналогичный подход .Есть мысли по поводу такого решения?Спасибо!
Кроме того, это не обязательно интеграционное тестирование (хотя это тоже может сыграть в это).Например, мы хотим провести модульное тестирование поведения бизнес-правила конкретной сущности - во время которого этот сценарий будет разворачиваться.
Я определенно открыт для абстракций объекта Http - я использовал их и любил их в MVC;как можно заставить их выйти за пределы MVC?