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

Полный сарказма ответ:

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

Чтобы упрощать структуру кода, там где это может быть полезно... не?

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

Старая история, 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 и прочим.

А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечиваются, а IDE мешает с навигацией по коду!

·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.

Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что простой найти метод без средств студии уже нереально А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге придется переносить во все зависимые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!

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

Полный сарказма ответ:

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

Чтобы упрощать структуру кода, там где это может быть полезно... не?

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

Старая история, 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 и прочим.

А все остальные способы создания сервисов в коде на этапе компиляции не проверяются, зависимости не обеспечивают, а IDE будет намеренно мешать навигации по коду!

·>Далее, если у тебя таки получается класс у которого очень много зависимостей это сразу явно видно по его конструктору. Это просто значит что данный класс превращается в Универсальный Всемогутор (https://en.wikipedia.org/wiki/God_object) и требуется рефакторинг: пилишь компоненты по зависимостям так, чтобы уменьшить максимальную валентность графа зависимостей.

Какая красота, люди ведь не замечают, что полдня работают с одним файлом кол-во строк которого перевалило за несколько тыс. И что простой найти метод без средств студии уже нереально А так — глянул конструктор и все понятно А то, что всю эту сервисную обвязку при рефакторинге придется переносить во все зависимые классы. Ну это фигня не упаримся. Нам работу компилятора выполнять не в тягость!