Здравствуйте, Somescout, Вы писали:
IT>>А раз так, то как же можно получить информацию о кастомере без DI фреймворка и пары IoC контейнеров? Никак не можно. S>Кстати, а если действительно никак не можно — например информация о кастомере разбросана по нескольким сервисам?
И как тут поможет DI фреймворк?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, microuser, Вы писали:
M>>Как это читаемость будет меньше при большем количестве ничего не делающего кода?
ARK>Во-первых, количество кода не обязано быть больше. Это утверждение — не аксиома и нуждается в обосновании. ARK>Во-вторых, читаемость зависит не только от количества кода.
M>>Еще раз говорю, покажите реальный проект без DI или хотя бы CRUD заготовку.
ARK>Любой (почти) проект на гитхабе бери, там DI не будет никакого.
CalculatePriceHandler нигде руками не создается, так же как и его зависимость IDataStore, все достается из контейнера. Теперь ваша очередь, покажите любой CRUD проект без DI.
Классный пример. На первый взгляд код с DI получается короче. Но если внимательно присмотреться, то можно заметить, что код без DI самодостаточен и понятен, а краткость без DI достигается банальным опусканием реализации некоторых объектов Даже в таком мелком примере умудрились всё запутать
Если нам не помогут, то мы тоже никого не пощадим.
Откуда-то взялось дополнительное условие "CRUD-проект".
Ну вот первый попавшийся: https://github.com/dlang/dmd/tree/master/src/dmd
Догадываюсь, что это не "CRUD-проект" (что бы это ни значило), но подозреваю, что сложность его на пару порядков больше, чем типичного "круда". Однако, почему-то напрямую вызываются конструкторы, без всяких инъекций.
Здравствуйте, Sinclair, Вы писали:
S>>Ок, простой пример: на веб странице компонент должен выводить имя текущего пользователя. Он должен его откуда-то получить: либо вы при рендеринге каждой страницы прокидываете эту информацию ему вручную, либо компонент так или иначе (через DI, репозиторий, синглтон) получает эту информацию сам. S>Ну это же прекрасный пример. Через три-четыре релиза у нас в топ жалоб выезжает "ваше приложение нещадно тормозит", привлекается команда высокооплачиваемых экспертов, которые после трёх месяцев расчистки конюшен констатирует очевидное: "у вас там каждая кнопка в гуе считает, что ей нужно лазить в базу/сторонний сервис/ещё куда-то, в итоге для построения одного экрана открывается 27 коннектов к базе, и исполняется более трёхсот SQL-запросов. Из них треть дублируют друг друга, а половина, хоть и не совпадает, может быть покрыта одним из более широких запросов". Рекомендация экспертов: "чётко разделить фазы построения гуя, доставая данные из базы минимальным количеством запросов и передавая визуальным компонентам готовую viewModel".
А DI то тут причем? Не вижу связи с оптимизацией sql запросов, что правильно, и DI. Тоже самое отменно может быть
и без плюшек DI.
Здравствуйте, AlexRK, Вы писали:
ARK>Это все как раз про DI. Особенно читаемость — она там где-то в районе нуля.
Ну тормоза то будут на старте, при создании графов объектов.
ARK>Плюс лишние тормоза и еще потеря статической типизации в точке получения объекта.
Не будет там потери, просто меньше компилятора предупреждений от компилятора переедут в
падение во время исполнения -- при запуске, например. Я выше ссылку на SO привел. Т.е.
если где-то чего-то не хватает, мы узнаем только при запуске.
Здравствуйте, AlexRK, Вы писали:
S>>То, что в недрах гуя нет простого доступа к DBConnection — это хорошо, а не плохо. Так что нам не нужно средство, которое даёт эту невыносимую лёгкость сделать "а шандарахну-ка я тут запросец в базу". ARK>Плюс адин. Провоцирует на повышение связности на ровном месте. В результате на выходе Big Ball of Mud.
Нет, провоцирует сложность конфигурации и т.п. Связность как была низкой -- по интерфейсам -- так и осталось.
Здравствуйте, TG, Вы писали:
TG>>>Или получается, что DI полезен только вот в таких "хитрых" архитектурах? S>>Что "хитрого" в такой архитектуре? TG>Фраза "Допустим мне в глубинах компонентов понадобился доступ к базе" намекает, что при проектировании несколько подзабыли принципы SOLID, разделение на слои и т.д. И если сделано это осознанно, то было бы опять же интересно посмотреть на конкретный кейс.
Скорее про DDD какое-нибудь забыли\отступись, а доступ в глубинах компонентов к бд можно и по SOLID сделать.
Здравствуйте, IT, Вы писали:
S>>Это, вобще-то, и есть dependency injection. Только вы это вручную делаете, и фактически переносите проблемы на уровень выше: теперь вызывающий код в обязательном порядке должен иметь ссылку на базу (напрямую или через DatabaseHelper), и сам должен получить userDao — что поменялось в итоге от такой перетасовки? Ничего — все проблемы ровно на том же месте. IT>Как минимум поменялось то, что теперь это всё делается явно. Не надо гадать кто, где, когда, зачем. Этот код можно перенести в другой проект и он либо будет работать, либо не скомпилируется. А в случае с контейнерами он скорее всего скомпилируется, но работать не будет.
Вроде договорились, что серебряной пули не существует. Программист может абстрагироваться от кучи
реализаций абстракций, их конфигурации и т.п., а просто будет работать с тем, что есть, т.е. дадут\сконфигурируют.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, microuser, Вы писали:
M>>Ну взял первый попавшийся, DI на месте: M>>https://github.com/asc-lab/dotnetcore-microservices-poc/blob/master/PricingService/Commands/CalculatePriceHandler.cs M>>CalculatePriceHandler нигде руками не создается, так же как и его зависимость IDataStore, все достается из контейнера. Теперь ваша очередь, покажите любой CRUD проект без DI.
ARK>Откуда-то взялось дополнительное условие "CRUD-проект". ARK>Ну вот первый попавшийся: https://github.com/dlang/dmd/tree/master/src/dmd ARK>Догадываюсь, что это не "CRUD-проект" (что бы это ни значило), но подозреваю, что сложность его на пару порядков больше, чем типичного "круда". Однако, почему-то напрямую вызываются конструкторы, без всяких инъекций.
Конечно не CRUD и естественно здесь никакой DI не нужен. Просто потому что здесь сложности в создании объектов никакой нет, их тут всего штук 50(судя по количеству файлов) и они не меняются так как бизнес логики нет, а новые будут добавляться лишь изредка. По большому счету компилятор это функция которой на вход подаются исходники, а на выходе исполняемый файл. DI нужен в "энтерпрайз" разработке, где куча разнообразной логики которая имеет свойство часто меняться, это приводит к тому что меняются сигнатуры конструкторов, их зависимости и т.д.
Здравствуйте, Министр Промышленности, Вы писали:
МП>в таком описании становится понятно, что оставление DI в проекте есть ни что иное как технических долг... МП>просто по завершении работ по быстро обновимшимся требованиям забили болт на реформирование структуры классов по сборкам
Скорее гарантия гибкости и производительности программиста -- не надо разбираться с кучей сервисов, их
отличий, особенностей и т.п. , а просто "заказать" себе текущую реализацию (интерфейс) и плясать от нее.
Здравствуйте, TG, Вы писали:
TG>А почему оставим-то? Это очень интересный вопрос. TG>Или получается, что DI полезен только вот в таких "хитрых" архитектурах? TG>А если что-то пилить с нуля, то можно и обойтись без DI?
Наверное, даже нужно. Но если все это разрастется до энтерпрайза с постоянно меняющимися требования,
тогда придется использовать DI.
Здравствуйте, microuser, Вы писали:
M>Не совсем понимаю связь между неявной параметризацией функций, смешиванием бизнес логики и зависимостей от внешнего поведения. M>Все это вопросы архитектуры, а DI фреймворк лишь берет на себя ответственность за создание экземпляров объектов, работать он может в любой архитектуре. M>Хотелось бы real life пример бизнес приложения, или хотя бы CRUD hello world без DI.
Ну наше приложения я, естественно, тебе показывать не могу, а рыться по гитхабу не буду.
Но я тебе могу предложить кое-что лучше — целая статья на эту тему, где все разжевано на пальцах. https://fsharpforfunandprofit.com/posts/dependencies/
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, barn_czn, Вы писали:
_>>Конкретный пример пож-та, чтобы спор был не абстрактным.
AA>И да, еще больше примеров в книжке "Роберт Мартин — Чистая архитектура — 2018", после ее прочтения сомнения отпадают. AA>Так или иначе зависимости будут, использовать для этого ФВ или делать свой велосипед это уже от архитектора зависит. AA>Хотя да, большинство проектов на C# это монолиты.
причем тут c#? а на ява или с++ ни монолиты? Большинство проектов.. учитывая популярность Unity сейчас можно сказать что большинство проектов на шарпе — полный гавнокод от школьников. Шарп тут не причем как ЯП.
AA>В корэ использую стандартный DI очень доволен. можно в любом месте приложения получить ссылку на любой объект не задумываясь.
AA>https://github.com/altbodhi/HostAppExample/blob/master/Program.cs
Все равно ни понял. Контексты всегда были и без DI (Control.Parent, Control.Application, Request.Host и т.д). Добирайся нихочу.
Но вот если есть конструктор у App, а я явно не вижу место его вызова — меня это напрягает. Таких неявных мест должно быть по минимуму.
Здравствуйте, IT, Вы писали:
IT>Я такое при возможности выкорчёвываю нещадно. На самом деле есть очень простой и эффективный критерий правильно написанной бизнес логики. Если логически законченный функционал бизнес логики легко извлекается из одного проекта и спокойно переносится в другой, то это правильно написанная бизнес логика. Если же для переезда в соседний дом нужно перетащить с собой весь подъезд, то это не код, а кусок оверинжениринга.
для переиспользования бизнес-логики нужна интеграция, а не копирование (репо, артефактов, классов...). последствия последнего объяснять, думаю, не надо.
и, бинго, даже интеграция делается через некий интерфейс. в случае необходимости его версионирования вводится политика EOL по каждой версии.
Здравствуйте, vsb, Вы писали:
vsb> Поздравляю, вы только что показали пример использования паттерна Dependency Injection. vsb> А фреймворк даст возможность не писать эти две строчки.
Это лукавство. Вместо этих двух строчек надо будет строчки в конфигурации и пара аннотаций, которые хрен протестируешь.
vsb> Которые разрастутся в сотни и тысячи строк однотипного скучного кода в реальном приложении с десятками-сотнями объектов
Точно. А вот конфигуации прямо таки веселье и праздник!
Здравствуйте, IT, Вы писали:
IT>Какая прелесть! А кто мешает один раз написать для базы данных какой-нибудь рапер/хелпер, который будет решать все эти вопросы без DI?
Ок, напишу я его, а прокинуть его как? И я опять же не понимаю: зачем "решать эти вопросы без DI" — как это облегчает работу?
Если нам не помогут, то мы тоже никого не пощадим.
Даже в таком мелком примере умудрились всё запутать 
