я думал хотя бы в вопросе использовать DI или нет сообщество консистентно

Консистентно, конечно. Просто ты границы сообщества не там провёл.

романа выносим за скобки?

@ilchert на всякий случай уточню, я имел ввиду, что IoC containers не нужны. Constructor Injection норм

о, ярлычки пошли

Но мы вообще пишем на фшарпе — языке для белых господ, великом наречии, недоступном для простых гребцов

так я ж писал выше, что там где контейнер прибит гвоздями, мы используем его. По крайней мере те его элементы, которые прибиты гвоздями

у тебя есть НДА? можешь показать пример реального кода с 10-20 сервисами?

у тебя есть НДА? можешь показать пример реального кода с 10-20 сервисами?

мб могу. Но сможешь ли ты прочесть фшарп?!111

мб могу. Но сможешь ли ты прочесть фшарп?!111

и чтобы все в одном конструкторе @atsapura иначе нещитово!!1

блин, у нас минимум 4 конструктора

Ну всё понятно.

@ilchert короч на днях я заварганю нормальный пример. Чтоб утереть нос вам всем раз и навсегда

ты из тех, у кого особый путь)

Зависимость от IoC контейнера - это именно асп.нет и спринговые проблемы. Ну и в больших проектах может иметь смысл. А так уже несколько лет пишу без них код (что на скале, что на том же расте) и как-то проблем в микросервисах от этого нет.

согласен, калькулятор на контейнерах - это слишком

Ну вопрос что считать калькулятором.

У меня где-то в 20к строк сервисы нормально без DI работают.

весь бцл работает без иока, и он там не нужен

https://zenrus.ru/

Глаз радуется

Ммм зп в валюте получаешь?)

Ммм зп в валюте получаешь?)

Зависимость от IoC контейнера - это именно асп.нет и спринговые проблемы. Ну и в больших проектах может иметь смысл. А так уже несколько лет пишу без них код (что на скале, что на том же расте) и как-то проблем в микросервисах от этого нет.

Не жили богато — нехер начинать, да.

Вы начинаете двигать goalposts со своими «небольшими»

Ну если ручное создание графа зависимостей растягивается (или есть ощутимые шансы, что оно таким станет) на некрасивую и здоровенную портянку кода под сотню строк - то вот наверное и пришло время IoC контейнер использовать. Ну и в аспнет экосистеме на IoC много чего завязано, поэтому там я особо не вижу смысла его не использовать, потому что против подхода экосистемы идти не очень удобно на практике.

Чтобы лучше понять как работать без DI, стоит просто поковырять системы без DI в принципе

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

Оба языка - нишевые, и по всей видимости тупиковые ветви развития, но даже если и нет, то ты все равно не угадаешь, что там будет через 10 лет. Совершенно не удивлюсь, если в русте 50% стдлибы будет занято DI и IoC, от них вполне можно этого ожидать

Ну если там изобретут удобный к использованию IoC контейнер без особой инфраструктурной цены, то я бы его и взял бы с удовольствием.

Что как бы говорит нам, что дело не в принципе, а в эргономике [не-]существующих решений на сегодняшний день. Тогда как товарищ выше пытается опротестовать идею на концептуальном уровне

Ну я даже не прям уверен, что дело тут в принципе (или я просто читал обсуждение не тем местом). @atsapura А, например, compile-time IoC контейнер тебя устраивает в принципе?

Без стандартного контейнера никуда - даже http запрос нормально не сделать

У меня как-то получается

Ты стараешься!

Я пишу new http client и вперёд

А как же полли, логирование, кеширование соединений?

Нахер это всё надо в хеллоу ворлде?