AA>·>var dbOptions = new DbOptions()
AA>·> .UseSqlServer(Configuration.GetConnectionString("DefaultConnection"));
AA>·>var dbContext = new DbContext(dbOptions);
AA>·>var mainService = new MainService(dbContext);
AA>·>services.AddHostedService(mainService);
AA>·>
AA>·>Код внезапно стал проще — никаких лямбд, генериков, рефлексии, даункастов. Можно использовать IDE вовсю — find usages, declarations, использовать рефакторинги.
AA>Серьезно? "найти все ссылки" работает прекрасно и в первом случае. AA>Рефакторинг? Назовите хоть одну проблему.
да это уже описано несколько раз в теме, в том числе и мной
AA>DI никуда ни делся, только добавили кучу не нужных new.
а у нас какие-то проблемы с ключевым словом new ?
я пропустил новые веяния может это теперь как goto?..
а с var или int сейчас всё на рынке норм? for?
AA>Это отлично работает если у вас развитые средства рефакторинга, но это признак сильных зависимостей.
да средства рефакторинга довольно развитые
я подсел на решарпер
но и сама студия подтягивается к нему постепенно
работать вообще последние годы стало даже приятно
Властитель слабый и лукавый, Плешивый щёголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
Здравствуйте, varenikAA, Вы писали:
AA>·>Код внезапно стал проще — никаких лямбд, генериков, рефлексии, даункастов. Можно использовать IDE вовсю — find usages, declarations, использовать рефакторинги. AA>Серьезно? "найти все ссылки" работает прекрасно и в первом случае.
Не работает, например, "где используется данный _инстанс_ dbContext". В первом случае можно поискать только по имени класса, но не отследишь в какой момент конструируется инстанс класса и куда он уходит.
Контейнеры более нормально работают только когда wiring код чисто линейный, каждому типу соответствует ровно один инстанс и если используются какие-то идущие из коробки примочки, навроде request scopes и т.п. Но в этом случае и ручной DI делается левой пяткой, IDE сама всё пишет, даже мозг включать не надо. Зато если чуть шаг в сторону, то сложность контейнеров возрастает на порядок, теряется статический контроль, идёт завязка на специфику конкретного контейнера. В то время как обычный код ручного DI это таки обычный код, который можно модифицировать/рефакторить как любой другой код.
AA>Рефакторинг? Назовите хоть одну проблему.
Первое что в голову приходит — удаление зависимости.
Добавление зависимости — тоже проблема, т.к. до тех пор пока не запустишь, не узнаешь, что новая зависимость действительно есть и доступна.
AA>DI никуда ни делся,
Верно. В том-то и оно. DI — нужен. Контейнер — не нужен.
AA> только добавили кучу не нужных new.
Ещё скажи, что удалили кучу очень важных и полезных AddSingleton, GetService, as, лямбд и прочего.
AA>От интерфейсов м механизма DI все равно никуда спрятаться в клиентском коде, хотя для получения ссылки, хоть для создания локального скоупа,
Интерфейсы оротогональны DI. Можно с ними, можно без них. Обрати внимание, в моём фрагменте кода упоминания интерфейсов нет. И не должно быть, ибо это не забота DI.
AA>либо придется всюду делать ссылку на реализацию. Это отлично работает если у вас развитые средства рефакторинга, но это признак сильных зависимостей.
Нет, не придётся. Интерфейсы нужны там где они нужны и не нужны там где они не нужны. И фреймворк мне тут не указка.
Впрочем, это относится больше к конкретным ЯП. Скажем, в Java можно мокать обычный класс, интерфейсы для тестов не нужны. В c# с этим проблема. Там приходится интерфейсы создавать по поводу и без повода.
AA>Вообще если посмотреть на техники ФП, то там все на интерфейсах(любая функция по сути это он и есть), AA>только за счет возможностей ЯП еще и вызов зависимости выносится за скобки, т.к. есть возможность создавать AA>вычислительные выражения.
Это всё хорошо, но всё-таки на разных языках надо писать по разному, не надо сводить к общему знаменателю. А "могу писать фортран-программы на любом ЯП" — это, извините, банальное ламерство.
AA>"польза" Dependency Injection для ЯП типа C# очевидна. Не понимаю, почему нужно изобретать велосипед, когда есть отличная билт-ин реализация в коре(быть может вы все еще работает на легаси, тогда — да, только лисопед)?
Так DI или DI-контейнер?
Конкретно контейнер ничего полезного не делает, только сложность создаёт на пустом месте. В этом и проблема.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, varenikAA, Вы писали:
AA> TG>Вроде, про полезность интерфейсов никто не спорит. AA> TG>Изначальная мысль была: "Просто делай то же самое, но без контейнера." AA> Если разным частям приложения нужны общие объекты, то без контейнера не обойтись, просто это будет велосипед.
Обойтись, конечно. Непонятно, велосипед для чего? Для передачи параметра? Просто передаёшь общий объект разным частям приложения и... собственно всё. Да, вот так всё просто.
AA> Конечно, если это хеловорд, то можно без DI-контейнера, но вопрос как раз о зависимостях как таковых, а не о контейнере который упрощает работу с зависимостями (см тему).
Так продемонстрируй упрощение. Мой фрагмент кода получился проще твоего.
Здравствуйте, ·, Вы писали:
AA>> Конечно, если это хеловорд, то можно без DI-контейнера, но вопрос как раз о зависимостях как таковых, а не о контейнере который упрощает работу с зависимостями (см тему). ·>Так продемонстрируй упрощение. Мой фрагмент кода получился проще твоего.
Простота вещь относительная, если катану в руках никогда не держал, то можно и ногу себе отрубить.
Здравствуйте, Министр Промышленности, Вы писали:
МП>да это уже описано несколько раз в теме, в том числе и мной МП>а у нас какие-то проблемы с ключевым словом new ? МП>я пропустил новые веяния может это теперь как goto?.. МП>а с var или int сейчас всё на рынке норм? for? МП>да средства рефакторинга довольно развитые МП>я подсел на решарпер МП>но и сама студия подтягивается к нему постепенно МП>работать вообще последние годы стало даже приятно
Тема высосана из пальца. "О пользе Dependency Injection". Зачем писать в заголовке одно, а в теме другое?..
В чём особоый смысл new, необходимость в прикладном коде? Хотя быть может это другая тема...
def dict = Dictionary();
Если нет new то появляется возможность передавать конструктор в качестве параметра, т.к. это обычная функция возвращающая объект.
Nemerle отказался от него и получил почти ту же мощь, что и CL.
В F# почему-то до сих пор раздражающее сообщение от компилятора:
warning FS0760: Рекомендуется создавать объекты, поддерживающие интерфейс IDisposable с помощью "new Type(args)", а не "Type(args)" или "Type" в качестве значения функции, представляющего конструктор; это делается для того, чтобы указать, что ресурсы могут принадлежать созданному значению.
Так и не узнал в чем сакральный смысл этого оператора.
Против goto в C# ничего против не имею, т.к. его возможности ограничены локальной областью.
Если я использую asp.net core то из коробки получаю кучу возможностей т.к. это ФРЭЙМВОРК с готовыми решениями.
Если я как вы предлагаете все это выброшу на помойку, то мне придется все изобретать самому, т.к. DI-контейнер — зло,
EF — зло, MS — зло,... и т.д.
Отличный способ завязать все "на себя". Но не лучший в перспективе поддержки такой поделки.
Здравствуйте, Министр Промышленности, Вы писали:
МП>С моей профессиональной точки зрения DI фреймворки не нужны.
Я их тоже недолюбливаю, но понимаю их выгоды (как и недостатки).
Есть случаи когда DI вообще удобное решение. Например, когда сам продукт — это расширяемая среда вроде MS VS. Представить скажем подсветку кода в вид инжектящегося компонента удобно и красиво. Не надо писать левый код регистрации. Все выглядит декларативно и красиво.
То что DI решает проблему написания кучи кода создающего объекты и передающего их в другие конструкторы тоже верно. Иногда объектов может быть очень много. Но есть тут и минусы. Код завязанный на коркретный DI хрен перенесешь в другой проект. Иногда DI заставляет вводить лишние абстракции. Скажем вводить интерфейсы там где у них никогда не будет более одной реализации. Иногда DI приводит к тому, что хрен поймешь, что за тип к тебе в реальности приехал и где та магия, которая к этому привела.
Многие проблемы DI происходят от того, что DI-фрэймворки динамические, создают граф зависимостей в рантайме. Если бы зависимости разрешались бы статически, при компиляции море проблем DI ушло бы.
Ну, а по жизни все просто. Вот есть в продукте DI и все через него сделано и ты вынужден использовать его и писать в соответствующем стиле. А если тебя свой проект, то выбор — это архитектурное решение.
Лично я обычно с неохотой иду на использование DI. Не поверите, но код отлично можно писать в процедурном стиле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Министр Промышленности, Вы писали:
МП>Они затрудняют распутывание кода,
Есть такое. Но это скорее проблема реализации DI.
МП>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом)
А вот это точно полная чушь. Прекрасно рефакторю код напичканный DI с помощью Райдера. Никаких проблем нет. Наоборот мощные рефакторинги Райдера помогают в этом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Министр Промышленности, Вы писали:
МП>С моей профессиональной точки зрения DI фреймворки не нужны.
Сложно ли ездить на машине?
Если не умееешь — да.
Если Да — ходите пешком, или даже изобретите велосипед(эх, прокачу!).
Нормальные люди выберут феррари.
Если придется выбирать между самодельным велосипедом
и промышленной разработкой в которую вложен труд десятков специалистов,
и которая проверена многолетней практикой.
МП>>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом)
VD>А вот это точно полная чушь. Прекрасно рефакторю код напичканный DI с помощью Райдера. Никаких проблем нет. Наоборот мощные рефакторинги Райдера помогают в этом.
я райдером не пользовался до сих пор
у него есть фичи сверх решарпера?
в недрах темы я отчасти раскрыл что имею в виду:
использование элементов класса может быть неявным через IoC-фреймворк (сейчас понимаю лучше формулировать так)
увидев в IDE 0 количество использований — придётся озираться, а не использует ли его IoC-фреймворк, а не удалить сходу
Властитель слабый и лукавый, Плешивый щёголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
МП>>С моей профессиональной точки зрения DI фреймворки не нужны. VD>Я их тоже недолюбливаю, но понимаю их выгоды (как и недостатки). VD>Есть случаи когда DI вообще удобное решение. Например, когда сам продукт — это расширяемая среда вроде MS VS. Представить скажем подсветку кода в вид инжектящегося компонента удобно и красиво. Не надо писать левый код регистрации. Все выглядит декларативно и красиво. VD>То что DI решает проблему написания кучи кода создающего объекты и передающего их в другие конструкторы тоже верно. Иногда объектов может быть очень много. Но есть тут и минусы. Код завязанный на коркретный DI хрен перенесешь в другой проект. Иногда DI заставляет вводить лишние абстракции. Скажем вводить интерфейсы там где у них никогда не будет более одной реализации. Иногда DI приводит к тому, что хрен поймешь, что за тип к тебе в реальности приехал и где та магия, которая к этому привела. VD>Многие проблемы DI происходят от того, что DI-фрэймворки динамические, создают граф зависимостей в рантайме. Если бы зависимости разрешались бы статически, при компиляции море проблем DI ушло бы.
ну вот грамотный ответ, спасибо, как и ожидалось от Розового Слона
я в общем согласен
VD>Ну, а по жизни все просто. Вот есть в продукте DI и все через него сделано и ты вынужден использовать его и писать в соответствующем стиле. А если тебя свой проект, то выбор — это архитектурное решение.
если использование DI-фреймворка до моего прихода в проект внедрёно не слишком плотно, я его выкорчёвываю
VD>Лично я обычно с неохотой иду на использование DI. Не поверите, но код отлично можно писать в процедурном стиле.
я-то поверю, и сам так пишу (ну процедурный стиль + ООП конечно)
Властитель слабый и лукавый, Плешивый щёголь, враг труда,
Нечаянно пригретый славой,
Над нами царствовал тогда.... (А.С. Пушкин ? )
Здравствуйте, varenikAA, Вы писали:
AA>>> Конечно, если это хеловорд, то можно без DI-контейнера, но вопрос как раз о зависимостях как таковых, а не о контейнере который упрощает работу с зависимостями (см тему). AA>·>Так продемонстрируй упрощение. Мой фрагмент кода получился проще твоего. AA>Простота вещь относительная, если катану в руках никогда не держал, то можно и ногу себе отрубить.
Ты намекаешь, что у меня мало опыта с контейнерами. Это не так, совсем наоборот, и даже сейчас у приходится с бангалорским кодом возиться, более того я научился писать код и без контейнера. А ты сам говоришь, что не умеешь: "...то без контейнера не обойтись".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты намекаешь, что у меня мало опыта с контейнерами. Это не так, совсем наоборот, и даже сейчас у приходится с бангалорским кодом возиться, более того я научился писать код и без контейнера. А ты сам говоришь, что не умеешь: "...то без контейнера не обойтись".
Поздравляю! Что вы мне тут пытаетесь доказать? Что умеете сами управлять зависимостями? Хахаха!
AA>·>Ты намекаешь, что у меня мало опыта с контейнерами. Это не так, совсем наоборот, и даже сейчас у приходится с бангалорским кодом возиться, более того я научился писать код и без контейнера. А ты сам говоришь, что не умеешь: "...то без контейнера не обойтись".
AA>Поздравляю! Что вы мне тут пытаетесь доказать? Что умеете сами управлять зависимостями? Хахаха!
бери больше: "как управлять миром, не привлекая внимание санитаров"
ну, кстати, тоже из опыта работы с кодерами из бангалора-бангладеша: они часто любят понаписать какие-то свои контейнеры, аггрегаторы событий и всякое подобное, которое, естественно, не дружит ни с многопоточностью, не удаляется из памяти сборщиком мусора, но споровождается всё это тем самым : "теперь-то мы знаем, как оно работает"
Здравствуйте, Министр Промышленности, Вы писали:
МП>я райдером не пользовался до сих пор МП>у него есть фичи сверх решарпера?
С памятью проблем нет, так как 64битный. А так почти тоже самое.
МП>использование элементов класса может быть неявным через IoC-фреймворк (сейчас понимаю лучше формулировать так) МП>увидев в IDE 0 количество использований — придётся озираться, а не использует ли его IoC-фреймворк, а не удалить сходу
Это как бы проблема не IoC/DI, а использования базовых типов (интерфейсов и базовых классов) в проектировании. А она вызвана тем самым D из SOLID, т.е. dependency inversion principle, а не DI/IoC. DI лишь механизм для упрощения dependency inversion principle. Ты путаешь причину со следствием.
Ну, и если правильно пользоваться Райдером (думаю и Решарпером тоже), никаких проблем найти все реализации нет. Постоянно этим пользуюсь. F12 перейти к реализации. Ctrl+F12 — получить список реализаций или перейти к единсвенной.
В рантайме опять же можно видеть реальный тип.
Если использовать статический DI, во многих случаях можно будет конкретный тип предусмотреть.
Ну, а соблюдение Liskov substitution principle, т.е. L из SOLID позволяет не париться с тем, что у нас там за интерфейсом скрывается. Хотя, конечно, это больше самообман. Но если это не делать проблемы будут и без DI.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Буравчик, Вы писали:
Б>·>А для теста Б>·>
Б>·>new AppRoot(new MockDb(), new MockFilesystem(), new MockClock()...).run();
Б>·>
Б>Ну что, если мне не все зависимости надо мокать, а только две из десяти? Б>Остальные восемь мне хотелось бы взять "настоящие", уже подготовленные
Я не очень понял требования. Но в целом подход один и тот же. Ты описываешь явно что и как зависит в разных вариантах использования, где это надо использовать и для чего.
Допустим у тебя есть 10 чисто системных зависимостей. Т.е. у тебя AppRoot с 10 зависимостями и он используется в двух местах — в прод коде и в тесте. Притом в этих двух местах ты подсовываешь все разные зависимости.
Если вдруг тебе понадобится некий более крупный интеграционный тест, у которого только 2 зависимости из 10 отличаются от прода, то рефакторингом извлекаешь метод что-то вроде: createAppRoot(SomeDep3 d3, SomeDep10 d10) {return new AppRoot(new SomeDep1(), ...d3, new SomeDep9(), d10);} и используешь его в проде и в этом тесте, тогда как тот старый тест использует AppRoot напрямую, заменяя все 10 зависимостей.
Если где-то внутрях понадобится ещё некая 11-я зависимость, которую ты захочешь подменять в тестах, используешь рефакторинг introduce parameter и поднимаешь зависимость наверх до того места (AppRoot или createAppRoot) где нужно подменять.
И наоборот, если зависимости стали общими, то втаскиваешь их обратно.
В совсем сложных случаях сами зависимости могут собираться во множество модулей, которые сами по себе становятся компонентами с зависимостями и их можно объединять в ещё более крупные структуры. Т.е. получается иерархическая архитектура структуры приложения.
Т.е. для структурирования Composition Root используются те же техники декомпозиции, которые ты используешь для любого другого кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, VladD2, Вы писали:
МП>>использование элементов класса может быть неявным через IoC-фреймворк (сейчас понимаю лучше формулировать так) МП>>увидев в IDE 0 количество использований — придётся озираться, а не использует ли его IoC-фреймворк, а не удалить сходу VD>Это как бы проблема не IoC/DI, а использования базовых типов (интерфейсов и базовых классов) в проектировании. А она вызвана тем самым D из SOLID, т.е. dependency inversion principle, а не DI/IoC. DI лишь механизм для упрощения dependency inversion principle. Ты путаешь причину со следствием.
Это именно проблема IoC/DI, т.к. он может конфигурироваться из файла. При D. Inversion и без D. Injection у нас все равно как минимум
одно использование типа в коде будет (кто-то же должен его создать?). А при создание может конфигурироваться хрен знает где
и хрен знает как, и студия может об этом вообще ничего не знать. Вот и показывает, что тип нигде не используется, хотя
он явно прописан в конфиге как зависимость.
Здравствуйте, Sharov, Вы писали:
VD>>Это как бы проблема не IoC/DI, а использования базовых типов (интерфейсов и базовых классов) в проектировании. А она вызвана тем самым D из SOLID, т.е. dependency inversion principle, а не DI/IoC. DI лишь механизм для упрощения dependency inversion principle. Ты путаешь причину со следствием. S>Это именно проблема IoC/DI, т.к. он может конфигурироваться из файла. При D. Inversion и без D. Injection у нас все равно как минимум S>одно использование типа в коде будет (кто-то же должен его создать?). А при создание может конфигурироваться хрен знает где S>и хрен знает как, и студия может об этом вообще ничего не знать. Вот и показывает, что тип нигде не используется, хотя S>он явно прописан в конфиге как зависимость.
Особенно помню была мода на использование какого-нибудь component-scan, да ещё и по регекспам.
Т.е. если класс попадает в classpath и его имя удовлетворяет каким-нибудь регекспам, он имплементит некие интерфейсы, имеет некие аннотации — это всё влияет на его судьбу. Вот уж веселуха такое отлаживать! Зато "кода меньше™".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sharov, Вы писали:
S>Это именно проблема IoC/DI, т.к. он может конфигурироваться из файла. При D. Inversion и без D. Injection у нас все равно как минимум S>одно использование типа в коде будет (кто-то же должен его создать?). А при создание может конфигурироваться хрен знает где S>и хрен знает как, и студия может об этом вообще ничего не знать. Вот и показывает, что тип нигде не используется, хотя S>он явно прописан в конфиге как зависимость.
Что за "логика"? То что что-то там может — это не значит, что это является причиной. Ты создавая экземпляр можешь значительно больше чем любой фрэймворк. У нас вот проекте конфигурация из файла не используется в принципе. Вся конфигурация в коде.
Если у тебя в коде интерфейс, ты автоматически получаешь большую неопределенность нежели при работе с конкретным типом, так как ты работаешь с абстракцией. Работу с абстракцией выбираешь ты сам. Если этот выбор сделан осознанно и грамотно, а не потому, что "все так делают", то ты преследовал какую-то цель. И вот эта вот цель подразумевает подмену типа в рантайме. Используя DI ты волен создавать не только экземпляры конкретных типов, но и даже делать их все sealed, чтобы гарантировать, что они не могут быть подменены в рантайме.
Так что не говори чушь. Причина именно dependency inversion. Ты путаешь причину со следствием.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, вот так всё просто.
