Примечание 1: Я хочу прояснить это: я не пытаюсь лениво загружать зависимости или вставлять ленивые типы.
Большинство (все?) IoC-контейнеры требуют регистрации метаданныхс контейнером, чтобы описать, как какой-то тип должен быть разрешен при запросе;это включает в себя реализацию интерфейса, время жизни объекта и т. д. За последние пару лет API-интерфейсы на основе свободного / условного обозначения были добавлены в большинство (все?) IoC-контейнеров, что уменьшает много шума при предоставлении этогометаданные в контейнер.
С помощью ninject я использую подход, основанный на соглашениях, для регистрации своих метаданных, но я делаю это по требованию, а не авансом.Это дает огромную экономию производительности в сценарии интеграционного тестирования, где вы создаете ~ 10 объектов;вы теряете издержки, связанные с регистрацией всех зависимостей приложения в каждом тесте.
Примечание 2. Пожалуйста, не говорите мне, что вам не следует использовать контейнер IoC в интеграционном тесте.
Существует некоторое давление, чтобы перейти на использование компонентов Microsoft, когда они доступны, поэтому Unity на моем горизонте.У меня работает регистрация на основе соглашений, но я не могу понять, как «обнаружить» эти метаданные по требованию / лениво, как я мог бы это сделать в Ninject.
Моя первая попытка реализовать это была с использованием оболочки вокруг экземпляра UnityContainer.и после вызова GetInstance (type) для оболочки, я могу запросить контейнер, чтобы узнать, зарегистрирован ли тип.Если нет, я могу вызвать свои соглашения, найти метаданные и зарегистрировать тип.Однако этот подход углубляется только на один уровень;если этот тип внедряется с большим количеством зависимостей, каждая зависимость не возвращается обратно в метод GetInstance (тип), и, следовательно, моя дилемма.
Вопрос: как я могу лениво / по запросудобавить регистрации типов в Unity?
Источник был бы неплох, но указатель на ловушку в контейнере был бы так же хорош.Я пробовал наследование, но нечего переопределять, как в Ninject.