Сообщение Re[11]: О "наивном" DI и об архитектурном бессилии от 29.09.2016 7:12
Изменено 29.09.2016 9:27 IQuerist
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #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 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.
Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
PS и вот еще какая проблема — каждой сущности надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сущностями все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, а искать ее приходится как правило по интерфейсу.
·>Здравствуйте, #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 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.
Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
PS и вот еще какая проблема — каждой сущности надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сущностями все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, а искать ее приходится как правило по интерфейсу.
Re[11]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, ·, Вы писали:
·>Здравствуйте, #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 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.
Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, а искать ее приходится как правило по интерфейсу.
·>Здравствуйте, #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 параметрами на все случаи жизни. А когда на подходе дед-лайн новые классы будут создаваться копи-пастом вообще всех зависимостей самого жирного конструктора. И это в лучшем случае, в худшем максимальное количество данных будут передавать например на клиента в javascript чтобы допилить бизнес логику там. Т.к. там можно избежать всей этой возни с зависимостями и интерфейсами.
Да... метод наименьшего сопротивления.
Идеи то вроде бы и правильные, а вот их воплощение имхо абсолютно негодное.
PS и вот еще какая проблема — каждому "сервису" надо дать имя. И если методу еще как-то что-то можно вымучить исходя из его поведения. То с сервисами все обстоит гораздо хуже. Имена дают нелогичные, непонятные и ошибочные, камменты быстро деградируют и чтобы узнать о том, что же таки эта зависимость делает приходится лезть в ее реализацию, а искать ее приходится как правило по интерфейсу.