Сообщение Re[2]: О "наивном" DI и об архитектурном бессилии от 10.08.2016 7:29
Изменено 10.08.2016 8:05 IQuerist
Здравствуйте, Visor2004, Вы писали:
V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.
Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.
Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".
PS кстати в последствии это порождает наивные REST интерфейсы и переезд критической части бизнес логики в клиентские скрипты. Как я и определил ранее — Colonoscopy Injection (зависимость от очень конкретных сущностей повсеместное нарушение DI).
V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.
Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.
Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".
PS кстати в последствии это порождает наивные REST интерфейсы и переезд критической части бизнес логики в клиентские скрипты. Как я и определил ранее — Colonoscopy Injection (зависимость от очень конкретных сущностей повсеместное нарушение DI).
Re[2]: О "наивном" DI и об архитектурном бессилии
Здравствуйте, Visor2004, Вы писали:
V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.
Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.
Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".
PS кстати в последствии это порождает наивные REST интерфейсы и переезд критической части бизнес логики в клиентские скрипты. Как я и определил ранее — Colonoscopy Injection (зависимость от очень конкретных сущностей и повсеместное нарушение DI).
V>И каким же образом он эту концепцию нарушает? BoringItemDataReader небось нужна какая-то конфигурация, ConnectionString, например, а то и IDbContext для стабильной работы, который обычно имеет свое время жизни и правила создания/освобождения и доступен как часть подсистемы, которая хранит настройки, т.е. отдельный сервис в вашей терминологии. Так же может легко еще зависеть от 2-3 абстракций, кэша например и т.д. Мне доводилось видеть поделки людей, которые считали, что для реализации инфраструктуры проекта хватит 10 классов хелперов и все будет ништяк, заканчивалось еще хуже, чем переусложенное новичками DI.
Хорошее дополнение. Я собственно написал пост только потому, что те, кто реализует "наивный DI" ничего вами перечисленного не создают и даже не собираются. Они тупо инжектируют аналоги статических классов со статическими хелперными методами.
Проблема которую я описываю в другом... в пропаганде в среде новичков идеи о том, что если к статическим методам статического класса приделать интерфейс и создавать через DI. То это уже нифига не code smell, а "хорошая архитектура".
PS кстати в последствии это порождает наивные REST интерфейсы и переезд критической части бизнес логики в клиентские скрипты. Как я и определил ранее — Colonoscopy Injection (зависимость от очень конкретных сущностей и повсеместное нарушение DI).