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

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

J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Оказывается это называется Constructor Over-injection
·>тут вот разжевано с примерами: https://smarly.net/dependency-injection-in-net/di-catalog/di-refactorings/dealing-with-constructor-over-injection

Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы. Вроде дело нужное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascritp чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.

Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.

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

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

J>>·>Почему редко такой код встречается?..
J>>А если в классе UserService в методе Save для бизнес логики надо исспользовать разные *Managers,
J>>а в методе Delete еще более разные(UserProfileManager, AcitvityManager и т.д.).
J>>Передавать в UserService(FabricOfManagers fabric) — фабрику классов со всеми менеджерами?
·>Оказывается это называется Constructor Over-injection
·>тут вот разжевано с примерами: https://smarly.net/dependency-injection-in-net/di-catalog/di-refactorings/dealing-with-constructor-over-injection

Эх... ну вот опять вроде бы правильные и нужные вещи говорит дядя, но в итоге это выглядит — плодите интерфейсы, интерфейсы над интерфейсами и над ними еще интерфейсы. Может это дело потенциально полезное, но имхо мало кто будет этим заниматься на всех давят сроки, поэтому будут оставаться конструкторы с 20-30 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascritp чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.

Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.

PS и вот еще какая проблема — каждой сущности надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сущностями все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, как правило по интерфейсу.