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

IQ>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура?

Как мне кажется, этот момент — следствие попытки натянуть "классический" DI на все остальные области. Классический — это который пошёл от тяжёлых продуктов с продвинутым public API и поддержкой плагинов от сторонних разработчиков. Вот там возможность подсунуть нужные сервисы в код минимумом телодвижений — то, что надо.

К сожалению, DI в чистом виде абсолютно непригоден для использования в тяжёлом биз-коде. Там от DI требуется не закинуть сервисы и отдать объект, а способ протащить эти сервисы по длиннющей цепочке вызовов, причём состав зависимостей часто заранее неизвестен и определяется в рантайме. Для дотнета обсуждали вот тут

Автор: LWhisper
Дата: 30.05.16

.


IQ>Часть знакомых уверяла, что DI жизненно необходим для тестирования, но тут ситуация становилась совсем абсурдной, т.к. архитектурное решение (использовать DI) вроде как принималось, но никаких тестов при этом не было и в будущем они никогда не появлялись.
Вот да-да-да. На практике DI сам по себе никак не помогает и не упрощает процесс тестирования. Сложный код с полудесятком зависимостей одинаково неприятно покрывать тестами, что с DI, что без. Простой вообще не должен требовать DI для тестов


IQ>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции.
+1, только я бы немного по-другому сформулировал. Фраза "я добавил возможность" на уровне архитектуры на самом деле означает "теперь нам всем придётся это использовать". Сам по себе DI экономит кучу времени, но только до момента, когда он не вылезает из своей родной ниши. После этого лучше смотреть в сторону других инструментов.

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

IQ>Ребята... вот эта низкоуровневая "требуха" это что ли "сервис"? Вот эти все "внутренности наружу" это инкапсуляция и архитектура?

Как мне кажется, этот момент — следствие попытки натянуть "классический" DI на все остальные области. Классический — это который пошёл от тяжёлых продуктов с продвинутым public API и поддержкой плагинов от сторонних разработчиков. Вот там возможность подсунуть нужные сервисы в код минимумом телодвижений — то, что надо.

К сожалению, DI в чистом виде абсолютно непригоден для использования в тяжёлом биз-коде. Там от DI требуется не закинуть сервисы и отдать объект, а способ протащить эти сервисы по длиннющей цепочке вызовов, причём состав зависимостей часто заранее неизвестен и определяется в рантайме. Для дотнета обсуждали вот тут

Автор: LWhisper
Дата: 30.05.16

.


IQ>Часть знакомых уверяла, что DI жизненно необходим для тестирования, но тут ситуация становилась совсем абсурдной, т.к. архитектурное решение (использовать DI) вроде как принималось, но никаких тестов при этом не было и в будущем они никогда не появлялись.
Вот да-да-да. На практике DI сам по себе никак не помогает и не упрощает процесс тестирования. Сложный код с полудесятком зависимостей одинаково неприятно покрывать тестами, что с DI, что без. Простой вообще не должен требовать DI для тестов


IQ>Как-то так... имхо главная начальная проблема DI — неспособность разработчиков создавать объектные декомпозиции.
+1, только я бы немного по-другому сформулировал. Фраза "я добавил возможность" на уровне архитектуры на самом деле означает "теперь нам всем придётся это использовать". Сам по себе DI экономит кучу времени, но только до момента, когда он не вылезает из своей родной ниши. После этого лучше смотреть в сторону других инструментов.


UPD, P.S. Не стоит налегать на SOLID как на аргумент в спорах. Его к сожалению воспринимают как волшебную палочку, хотя на практике подход "потому что SOLID" работает не лучше, чем самолёт из культа карго. Голову никто не отменял