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

IQ>>Чтобы упрощать структуру кода, там где это может быть полезно... не?
·>Если в классе все методы статические, то какая именно польза от класса? Можно просто использовать namespace или что-то подобное.

Да класс превращается в старый добрый сишный модуль.

IQ>>·>Нет. Просто передаёшь всех менеджеров в конструкторе.
IQ>>·>UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
IQ>>·>Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current.
IQ>>Это иллюзия, код каждого конкретного метода читать все равно придется
·>Для чего?

Если надо выяснить какие сервисы он использует.

IQ>>·>И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
IQ>>А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!
·>Конечно, когда конструктор вызывается через рефлекию — IDE ничем помочь не может. А уж если XML-кофиги вспомнить...

Но это же самые любимые техники "наивного DI".

·>Синглтоны скрывают структуру зависимостей и порядок инициализации.

Это хороший аргумент... но часто порядок инициализации не имеет значения. А если инициализация сложная, то я лично поостерегся бы отдавать ее на откуп малознакомому фреймворку.