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

S>>Про настройку времени жизни в DI и request-scope я так понимаю вы ни сном ни духом?
S>Нет, почему же.
Да потому же — вы говорите про 27 коннектов и 300 запросов, хотя как раз DI позволяет в такой ситуации переиспользовать один контекст с одним соединением и кэшированием запросов.

S>Просто приведённый пример не может служить аргументом в пользу DI-контейнеров. То, что в недрах гуя нет простого доступа к DBConnection — это хорошо, а не плохо. Так что нам не нужно средство, которое даёт эту невыносимую лёгкость сделать "а шандарахну-ка я тут запросец в базу".
Ок, а если в этом месте нужны данные из базы — что именно вы предлагаете с этим делать?

S>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию.
У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.

S>Может быть, конечно, я преувеличиваю масштаб проблемы,
Нет, вы докопались до DbConnection (знал бы что вас на нём заклинит — написал бы DAO или "Сервис получения данных (с) (tm)")

S>но я в своё время нахлебался с системами, построенными по "чрезмерно компонентному" принципу. Типа "у нас есть набор универсальных кубиков, и мы в рантайме собираем из них нужное нам приложение". В итоге оказывается, что насквозь процедурный код инициализации зависимостей прекрасно отлаживается, рефакторится, и версионируется штатными средствами; а все чудеса "внешней конфигурации" — нет. Просто в рантайме почему-то в конкретный компонент уезжает не тот же самый DBConnection, что и у всех (или, наоборот, тот же самый, вместо нужного отдельного), или ещё какая пежня творится. А понять, кто в какой момент что там оверрайдит, и откуда взялись вот эти вот параметры конструктора — упражнение не для слабонервных.
То есть с компонентными системами нахлебались, а с процедурными, которые тянут напрямую связи во все зависимые компоненты — нет.

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

S>>Про настройку времени жизни в DI и request-scope я так понимаю вы ни сном ни духом?
S>Нет, почему же.
Да потому же — вы говорите про 27 коннектов и 300 запросов, хотя как раз DI позволяет в такой ситуации переиспользовать один контекст с одним соединением и кэшированием запросов.

S>Просто приведённый пример не может служить аргументом в пользу DI-контейнеров. То, что в недрах гуя нет простого доступа к DBConnection — это хорошо, а не плохо. Так что нам не нужно средство, которое даёт эту невыносимую лёгкость сделать "а шандарахну-ка я тут запросец в базу".
Ок, а если в этом месте нужны данные из базы — что именно вы предлагаете с этим делать?

S>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию.
У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.

S>Может быть, конечно, я преувеличиваю масштаб проблемы,
Нет, вы докопались до DbContext(знал бы что вас на нём заклинит — написал бы DAO или "Сервис получения данных (с) (tm)")

S>но я в своё время нахлебался с системами, построенными по "чрезмерно компонентному" принципу. Типа "у нас есть набор универсальных кубиков, и мы в рантайме собираем из них нужное нам приложение". В итоге оказывается, что насквозь процедурный код инициализации зависимостей прекрасно отлаживается, рефакторится, и версионируется штатными средствами; а все чудеса "внешней конфигурации" — нет. Просто в рантайме почему-то в конкретный компонент уезжает не тот же самый DBConnection, что и у всех (или, наоборот, тот же самый, вместо нужного отдельного), или ещё какая пежня творится. А понять, кто в какой момент что там оверрайдит, и откуда взялись вот эти вот параметры конструктора — упражнение не для слабонервных.
То есть с компонентными системами нахлебались, а с процедурными, которые тянут напрямую связи во все зависимые компоненты — нет.