Comments 4
Мне нравится терминология, принятая в Simple Injector. То, что вы называете «политика» (я так понимаю, политика, определяющая время жизни экземпляра), там называют lifestyle, а «конечные реализации политики» — это там Transien (ваш non-shared), Singleton (ваш shared), Scope, Per Web Request, Per WCF Operation, Per Lifetime Scope, Per Graph, Per Thread, Hybrid + есть возможность создать пользовательский lifestyle. Но сам контейнер как-то не вдохновил, Autofac с его монадическим синтаксисом (+ иногда критикуемая, но нужная, возможность вешать несколько реализаций на один интерфейс — через именование) лучше смотрится. «Запроса экспорта» — «Разрешение зависимости» (хотя тут спорно, «запрос экспорта» мне тоже нравится, более конкретно, но может точнее будет «запрос реализации», «запрос экземпляра»). Ну и «область видимости» — это наверное всё тот же lifestyle? В чём разница между вашей политикой и областью видимости (в рамках статьи)?
Это не мой NonShared, это MEF-овский NonShared. :) И policy, которую я перевожу как политика, тоже. Единственно, что я называю по-другому — это та самая область видимости, которая в MEF есть «политика создания». Почему область видимости, а не время жизни? Потому, что контейнер не управляет временем жизни объектов в полной мере, он их максимум только создает. Моя политика, наравне с политиками MEF собственно и определяет область видимости объекта.
А если у импортируемого объекта есть свои импортируемые объекты (любой степени вложенности), то политика создания распространяется и на них?
Sign up to leave a comment.
Определение собственных областей видимости в MEF