Здравствуйте, IT, Вы писали:
IT>Как минимум поменялось то, что теперь это всё делается явно. Не надо гадать кто, где, когда, зачем.
Я уже который раз не понимаю зачем нужно гадать? DI вполне явно инициализируется. Нет, безусловно могут быть ситуации, когда инициализация сделана через аттрибуты, да ещё и в другой assembly, да ещё и без исходников — но это уже проблемы архитектуры, а не DI.
IT>Этот код можно перенести в другой проект и он либо будет работать, либо не скомпилируется. А в случае с контейнерами он скорее всего скомпилируется, но работать не будет.
А что мешает перенести инициализацию DI и всё тогда тоже будет работать? Не говоря уж о том, что если в прицнипе стоит вопрос о "использовать DI или нет", значит код уже нетривиальный и просто так не переедет.
Здравствуйте, IT, Вы писали:
IT>>>А раз так, то как же можно получить информацию о кастомере без DI фреймворка и пары IoC контейнеров? Никак не можно. S>>Кстати, а если действительно никак не можно — например информация о кастомере разбросана по нескольким сервисам?
IT>И как тут поможет DI фреймворк?
Если у вас зависимость от множества сервисов, то прежде чем воспользоваться GetCustomer вам нужно их все получить. Да, можно обернуть это всё в Helper — но какой смысл плодить сущности без нужды?
Здравствуйте, Sinclair, Вы писали:
S>>Про настройку времени жизни в DI и request-scope я так понимаю вы ни сном ни духом? S>Нет, почему же.
Да потому же — вы говорите про 27 коннектов и 300 запросов, хотя как раз DI позволяет в такой ситуации переиспользовать один контекст с одним соединением и кэшированием запросов.
S>Просто приведённый пример не может служить аргументом в пользу DI-контейнеров. То, что в недрах гуя нет простого доступа к DBConnection — это хорошо, а не плохо. Так что нам не нужно средство, которое даёт эту невыносимую лёгкость сделать "а шандарахну-ка я тут запросец в базу".
Ок, а если в этом месте нужны данные из базы — что именно вы предлагаете с этим делать?
S>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию.
У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.
S>Может быть, конечно, я преувеличиваю масштаб проблемы,
Нет, вы докопались до DbContext(знал бы что вас на нём заклинит — написал бы DAO или "Сервис получения данных (с) (tm)")
S>но я в своё время нахлебался с системами, построенными по "чрезмерно компонентному" принципу. Типа "у нас есть набор универсальных кубиков, и мы в рантайме собираем из них нужное нам приложение". В итоге оказывается, что насквозь процедурный код инициализации зависимостей прекрасно отлаживается, рефакторится, и версионируется штатными средствами; а все чудеса "внешней конфигурации" — нет. Просто в рантайме почему-то в конкретный компонент уезжает не тот же самый DBConnection, что и у всех (или, наоборот, тот же самый, вместо нужного отдельного), или ещё какая пежня творится. А понять, кто в какой момент что там оверрайдит, и откуда взялись вот эти вот параметры конструктора — упражнение не для слабонервных.
То есть с компонентными системами нахлебались, а с процедурными, которые тянут напрямую связи во все зависимые компоненты — нет.
Здравствуйте, C0s, Вы писали:
IT>>Я такое при возможности выкорчёвываю нещадно. На самом деле есть очень простой и эффективный критерий правильно написанной бизнес логики. Если логически законченный функционал бизнес логики легко извлекается из одного проекта и спокойно переносится в другой, то это правильно написанная бизнес логика. Если же для переезда в соседний дом нужно перетащить с собой весь подъезд, то это не код, а кусок оверинжениринга.
C0s>для переиспользования бизнес-логики нужна интеграция,
Интеграция чего?
C0s>а не копирование (репо, артефактов, классов...). последствия последнего объяснять, думаю, не надо.
Никто и не говорил о копировании. Речь шла о переносе кода из одного проекта в другой.
C0s>и, бинго, даже интеграция делается через некий интерфейс. в случае необходимости его версионирования вводится политика EOL по каждой версии.
Вот вроде все слова понятные, а смысла не улавливаю. EOL — это end of line?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Somescout, Вы писали:
IT>>Какая прелесть! А кто мешает один раз написать для базы данных какой-нибудь рапер/хелпер, который будет решать все эти вопросы без DI? S>Ок, напишу я его, а прокинуть его как? И я опять же не понимаю: зачем "решать эти вопросы без DI" — как это облегчает работу?
Ты не правильно ставишь вопрос. Т.к. это ты добавляешь в проект новый инструмент, то вопрос должен ставится как "какую проблему этот инструмент решает, какие негативные последсвия вносит и каково их соотношение". Т.е. польза, вред, что больше.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Я такое при возможности выкорчёвываю нещадно. На самом деле есть очень простой и эффективный критерий правильно написанной бизнес логики. Если логически законченный функционал бизнес логики легко извлекается из одного проекта и спокойно переносится в другой, то это правильно написанная бизнес логика. Если же для переезда в соседний дом нужно перетащить с собой весь подъезд, то это не код, а кусок оверинжениринга.
C0s>>для переиспользования бизнес-логики нужна интеграция,
IT>Интеграция чего?
в данном случае важно — с чем, вот с ней, этой самой БЛ
C0s>>а не копирование (репо, артефактов, классов...). последствия последнего объяснять, думаю, не надо.
IT>Никто и не говорил о копировании. Речь шла о переносе кода из одного проекта в другой.
ага, перенос — не копирование?
C0s>>и, бинго, даже интеграция делается через некий интерфейс. в случае необходимости его версионирования вводится политика EOL по каждой версии.
IT>Вот вроде все слова понятные, а смысла не улавливаю. EOL — это end of line?
Здравствуйте, Somescout, Вы писали:
S>А что мешает перенести инициализацию DI и всё тогда тоже будет работать? Не говоря уж о том, что если в прицнипе стоит вопрос о "использовать DI или нет", значит код уже нетривиальный и просто так не переедет.
Давай мы сразу определимся. Речь идёт не о DI как таковом, а о DI фреймворках и всяческих IoC контейнерах. Ты сейчас про что?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Somescout, Вы писали:
IT>>И как тут поможет DI фреймворк? S>Если у вас зависимость от множества сервисов, то прежде чем воспользоваться GetCustomer вам нужно их все получить. Да, можно обернуть это всё в Helper — но какой смысл плодить сущности без нужды?
У меня нет множества сервисов, только база данных. Как тут поможет DI фреймворк?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, C0s, Вы писали:
C0s>>>для переиспользования бизнес-логики нужна интеграция, IT>>Интеграция чего? C0s>в данном случае важно — с чем, вот с ней, этой самой БЛ
Возможно. Но без "чего" я не улавливаю смысла в твоём сообщении. А с телепатией у меня всегда были проблемы.
IT>>Никто и не говорил о копировании. Речь шла о переносе кода из одного проекта в другой. C0s>ага, перенос — не копирование?
Не, не копирование. Впрочем, если ты о копипасте, то тут тоже не всё так однозначно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
C0s>>>>для переиспользования бизнес-логики нужна интеграция, IT>>>Интеграция чего? C0s>>в данном случае важно — с чем, вот с ней, этой самой БЛ
IT>Возможно. Но без "чего" я не улавливаю смысла в твоём сообщении. А с телепатией у меня всегда были проблемы.
"чего" — это "что-то", что должно от реализации этой БЛ зависеть.
IT>>>Никто и не говорил о копировании. Речь шла о переносе кода из одного проекта в другой. C0s>>ага, перенос — не копирование?
IT>Не, не копирование. Впрочем, если ты о копипасте, то тут тоже не всё так однозначно.
не всё, но я лишь говорю, что зависимость в таком случае должна достигаться по векторам деплоймента, а не путём копирования кода реализации БЛ, что мне показалось подразумеваемым твоим комментарием, на который я начал отвечать. допускаю, что у меня тоже телепатия просела.
Здравствуйте, IT, Вы писали:
IT>У меня нет множества сервисов, только база данных. Как тут поможет DI фреймворк?
у меня, например, был проект, в котором "только БД" клиент был вынужден шардировать на 4 отдельных инстанса. DI спас, так зависимость была строго по модели и интерфейсу её прокачки в обе стороны, а не источнику(ам).
S>>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию. S>У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.
потому что, мать его, столкнулись с последствиями его внедрения
Властитель слабый и лукавый, Плешивый щёголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
при всём уважении у меня не повернётся язык назвать такой retriever-метод бизнес-логикой
по крайней мере, тяжело представить такой метод изменяющимся часто на протяжении жизни проекта
C0s>>не всё, но я лишь говорю, что зависимость в таком случае должна достигаться по векторам деплоймента,
IT>Зависимости не должны достигаться. Они должны устраняться?
а как их устранить-то, если есть базовая зависимость по бизнес-требованиям?
в случае, когда БЛ подлежит эволюции, это будет означать, что конкретный алгоритм, берущий на вход A и порождающий B, может менять типы A и B, как формально, так и
семантически (при совпадении формальных типов ингредиентов, если так почему-то неудачно заложили сразу), а клиенты этого алгоритма должны подстраиваться под его эволюцию
при таком раскладе между копированием кода или же зависимостью по артефакту, что означает неконтролируемость по EOL, я рекомендую зависимость по деплойменту, которая отключается на стороне заинтересованного "сервера", а не путём поиска по дереву вниз всех нерадивых, кто не успел перейти на следующий вариант
ps. мы всё дальше отходим от DI, как фичи какого-то фреймворка
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Somescout, Вы писали:
IT>>>Какая прелесть! А кто мешает один раз написать для базы данных какой-нибудь рапер/хелпер, который будет решать все эти вопросы без DI? S>>Ок, напишу я его, а прокинуть его как? И я опять же не понимаю: зачем "решать эти вопросы без DI" — как это облегчает работу?
IT>Ты не правильно ставишь вопрос. Т.к. это ты добавляешь в проект новый инструмент, то вопрос должен ставится как "какую проблему этот инструмент решает, какие негативные последсвия вносит и каково их соотношение". Т.е. польза, вред, что больше.
Стоп. Давайте вы сначала покажете правильный (с вашей точки зрения) способ использования этого хелпера, а потом порассуждаем о достоинствах и недостатках. Иначе я буду просто предполагать, что вы предлагаете статический синглтон — и, думаю, не нужно говорить почему это плохая практика.
Здравствуйте, IT, Вы писали:
S>>А что мешает перенести инициализацию DI и всё тогда тоже будет работать? Не говоря уж о том, что если в прицнипе стоит вопрос о "использовать DI или нет", значит код уже нетривиальный и просто так не переедет.
IT>Давай мы сразу определимся. Речь идёт не о DI как таковом, а о DI фреймворках и всяческих IoC контейнерах. Ты сейчас про что?
О них в том числе. Я просто действительно не понимаю что именно вас в них смущает: у меня два проекта, когда из первого, построенного на DI потребовалось перенести компоненты во второй (без DI) — не возникло никаких проблем, я просто руками конструировал все объекты. Да, это неудобнее, да и управление временем жизни становится геморройным, но каких-то сложностей с переносом нет — ведь фактически это обычные классы без магии (DI выполнялся исключительно через конструкторы).
Здравствуйте, IT, Вы писали:
S>>Если у вас зависимость от множества сервисов, то прежде чем воспользоваться GetCustomer вам нужно их все получить. Да, можно обернуть это всё в Helper — но какой смысл плодить сущности без нужды?
IT>У меня нет множества сервисов, только база данных. Как тут поможет DI фреймворк?
Да я вроде уже в первом же комментарии это объяснял — вам не нужно конструировать контекст базы непосредственно внизу. А если абстрагироваться через интерфейсы, то компонент может вообще не знать с чем именно он работает — есть интерфейс для получения данных, он его и использует. А что за ним прячется: сама база, кэш или сервис — его не касается.
Здравствуйте, Министр Промышленности, Вы писали:
S>>>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию. S>>У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.
МП>потому что, мать его, столкнулись с последствиями его внедрения
То есть детский испуг? Ну накнулись на странную и непонятную штуку и "ААААА!!!!" (и под одеяло).
S>>>>А вообще, в целом, я согласен с теми из участников дискуссии, которые считают развитые DI-контейнеры всего лишь средством переноса сложности из исходного кода в конфигурацию. S>>>У меня складывается впечатление что некоторые участники дискуссии слегка побаиваются DI.
МП>>потому что, мать его, столкнулись с последствиями его внедрения
S>То есть детский испуг? Ну накнулись на странную и непонятную штуку и "ААААА!!!!" (и под одеяло).
нет
просто реально трудно и неприятно работать когда это нагорожено
Властитель слабый и лукавый, Плешивый щёголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
МП>уже со времён WCF сервисов заметил, что сложность конфигурирования зачастую превышает сложность кодирования
Потому что конфигурирование и есть кодирование.
Более того, "конфигурирование" требует ровно того же тестирования, что и "кодирование", и ровно такого же процесса выкатывания изменений.
Просто многие (порой даже как бы "сеньоры") этого не понимают, и думают, что если они назовут код "конфигурацией", то снова можено будет "як-як, и в продакшн". А то ведь, ишь, понапридумают — test coverage, unit testing, CI, — это ж надо понимать, что делаешь, как работает. А то еще и вовсе, о ужас, написать новый тест, да не просто тест, а такой, который убеждается, что в процессе "смены конфигурации" ничего не сломается.
Ведь куда проще же назвать это "конфигурационным флагом", и не тестировать. Зато потом следующий инженер, которому досталось наслоение таких "конфигурационных авгиевых конюшен", четко определит карму своего предшественника.
PS: написанное выше относится только к слову "конфигурация". Но не с dependency injection. Эта идиома по сути своей представляет не что иное как способ задавать интерфейс (API). Почему придумали новый термин... ну, сразу вот это вспоминается:
Если нам не помогут, то мы тоже никого не пощадим.
