Здравствуйте, Sinix, Вы писали:

S>·>Тем что это типичный technical debt. Если, конечно, не писать проекты-однодневки (а с ними всё просто — пиши как хочешь, всё пофиг), то потом от них придётся избавляться, что всегда довольно болезненно: рефакторить DI проще, чем GV или SL.
S>Ага! Наконец-то мне попался человек, который переделывает SL на DI, а не наоборот. Такой вопрос: а как вы решаете проблему цепочек зависимостей в бизнес-коде?
S>Ну, когда бизнес-сервис A вызывает B, тот — C и D и у всех есть свои уникальные зависимости?
Не совсем понял. Что за проблема-то? Вроде пишешь как слышишь:

class ServiceA
{
    ServiceA(SerivceB b, CommonDependency1 cd1, CommonDependency2 cd2, UniqueDependecyA uA...)
}
class ServiceB
{
    ServiceB(SerivceC c, SerivceD d, CommonDependency1 cd1, CommonDependency2 cd2, UniqueDependecy1 u1...)
}
...

И что приятно — оно тебя будет круто бить по рукам, если вдруг захочется создать циклическую зависимость (захочешь вдруг использовать A из C — будет облом).

S>·>А как ты реализуешь плагины с DI?
S>Как я понял, IQuerist про предоставление системного API плагинам, а не про встраивание самих плагинов. Для этого DI — самое оно, смотрим на extensions студии.
Я Студию смотрел последний раз больше лет 10 назад... Можно подробнее? Что за extensions?