hVostt,

Вы так и не ответили, как вы в своем решении работаете с временными-скопами.

Я так понимаю, что фабрику-обертку можно написать двумя способами:
Как указал Алексей К. 18882170 - через универсальный GetServices.
Либо как указал я 18884017 - через явное указание IService1 ResolveService1 (){}

В первом случае мне не ясно как вообще обеспечить защиту от GOD MODE ?
Разве что создавать разные IServiceProviderEx , конфигурировать их разным набором классов. Чтобы один мог резолвить только те, а другой только эти. Остается правда вопрос настройки взаимодействия объектов порожденных разными резолверам. И каждый раз при добавлении нового типа пройтись по резолверам и настроить права доступа. И если это никак не документировать то потом попробуй найди кто за что отвечает (в какой из десятка резолверов внедрить компонент). Вам знаком термин "dll hell" ? Думаю наступит именно он, если будет куча резолверов.

Во втором случае, в добавок к описанным строкой выше проблемам, начинаются проблемы с LifetimeScope.

Оба решения сложны в применении и, полагаю, существенно усложнят разработку программы и ее поддержку.

Говорите, что еще якобы сложность тестирования наступает, если передавать IDependencyResolver.
Но в чем сложность ? Замокайте IDependencyResolver который передается, и все. Можно хоть всю цепочку резолвинга замокать - чтобы мок генерил другой мок который сгенерит уже тестовый объект, который и будет применяться в тестировании.

Соглашусь, что есть риск, что какая-то сторонняя либа сможет получить IDependencyResolver после чего сможет делать что угодно. Но с другой стороны у нас получается сложность поддержки. Не знаю что выбрать из двух зол.

hVostt,

* Dependency hell

Владимир Путин-Ленин,

Ну вон статейка как раз про это.
http://blog.ploeh.dk/2014/06/02/captive-dependency/

Да любой пример, когда долгоживущий объект должен использовать короткоживущие. Если не уследить, будет примерна та же проблема, что с делегатами, которые как веревочка не дают удалить большой объект, С делегатами решается через слабые ссылки конечно, но говорим сейчас про DI - где для этого, вроде бы, и придуман LifetimeScope.

Хотя с Dependency hell я пожалуй загнул. Это не та проблема :)

ИзопропилАлексей КНо 1% всегда остаётся, про него и речь.
Что за процент - поясни на примерах

per-request lifetime support это прикладной или инфраструктурный код ? я уже запутался :)
Вот это нужно. После обработки каждого входящего запроса сервер будет чистить сгенеренный мусор.

ИзопропилАлексей КНо 1% всегда остаётся, про него и речь.
Что за процент - поясни на примерах

LifetimeScope чтобы в принципе существует, чтобы контролировать время жизни объектов. Это просто более высокоуровневая абстракция над IDisposable.
В принципе, наверное, можно обойти без передачи LifetimeScope пользовательскому коду.
Просто в этом случае нужно конфигурировать резолвинг объекта, указав, что "освобождаться он будет вне контейнера":
IRegistrationBuilder.ExternallyOwned Method