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

J>·>И какой тут смысл создавать инстанс UserService? Чем UserService.Save со статическим методом хуже?
J>Вообщем-то можно и статические методы исспользовать.
Зачем тогда классы вообще существуют?..

J>ConnectionParams ему можно передать из Singleton объектов.
Хррр. Имхо, это даже хуже чем IoC-контейнер.

J>·>Т.е. у тебя все зависимости будут синглтонами. Правильно понял? Жуть же. Типичный спагетти-код и радости дебага правильности порядка инициализации синглтонов.
J>Есть такое.
И ещё получается такой некий твой "class Settigs", который зависит от всего и все от него зависят.
Собственно IoC-контейнер позволяет этим хоть как-то рулить. Синглтоны однозначно в топку.

J>·>Почему редко такой код встречается?..
J>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
Нет. Просто передаёшь всех менеджеров в конструкторе.
UserService(UserProfileManager, AcitvityManager, SomethingManager, ...)
Да, конструктор _может_ получиться с тучей аргументов, но зато сразу видно что именно требуется для функционирования данного класса, тебе не нужно читать код каждого отдельного метода чтобы выяснить а что же этот конкретный метод в этой ветке if-условия решил вытянуть из глобального Context.Current. И, более того, это всё проверяется на этапе компиляции, все зависимости обеспечены, плюс IDE помогает с навигацией по коду, find usages, go to declaration и прочим.
Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.