Здравствуйте, IT, Вы писали:
IT>Я такое при возможности выкорчёвываю нещадно.
Только в случае использования asp.net core, и даже просто голого GenericHost1 уже все, выкорчевать ничего не выйдет, оно там прибито намертво гвоздями.
Здравствуйте, C0s, Вы писали:
C0s>этот пример никак не связан с DI, а напрямую зависит от правильного разделения по слоям и подходу к контекстуализации сессий на нижележащем слое
Еще как связан. Потому что в DI контейнере, если уж ты засунул туда фабрику коннектов к БД, нет никакого способа ограничить его использование. А вот если ты напрямую передаешь коннект, то ты легко можешь отдавать его строго в тот слой, которому можно работать с коннектами к БД.
Здравствуйте, VladD2, Вы писали:
VD>По ходу ты не понимаешь того что лежит за DI. Основная фича DI — это расчет графа зависимостей и автоматическое создание объектов в последовательности зависимостей.
Нет. Основная фича DI контейнеров — управление созданием и уничтоженим экземпляров сервисов, и рантайм биндинг этих экземпляров к потребителям (слово injection в названии четко и недвусмысленно определяет что такое DI). Что то там рассчитывать на графе зависимостей — совершенно необязательная фича, которой может просто не быть.
Здравствуйте, Sharov, Вы писали:
S>·>Мде уж. Это у тебя полная путаница. Основная фича DI — это отделить конструирование компонентов от их использования. S>Без графа зависимостей этого не сделаешь?
Что именно не сделать без явного графа зависимостей?
Здравствуйте, VladD2, Вы писали:
VD>С памятью проблем нет, так как 64битный.
Решарпер что в Райдере, что в студии все равно сидит в своем собственном 64-битном процессе.
VD> А так почти тоже самое.
Тоже, да не совсем. СОМ-ядро студии, увешанное блокировками, как бродячая собака блохами, начиная с некоторого размера проекта требует для работы с ней или сноса решарпера, или обретение дзена и спокойное ожидание когда внезапно подвисшая прям в процессе набора кода студия отвиснет. У Райдера этой проблемы нет.
Здравствуйте, Sharov, Вы писали:
S>Это именно проблема IoC/DI, т.к. он может конфигурироваться из файла.
А может? Я уж даже забыл о этой мегафиче и не мог понять о какой замене кода на конфигурацию рассказывает СкайДенс.
Эта хрень была в самых первых DI фреймворках. Потом быстро появилаась возможность конфигурации из кода, а в свеженьком DI от MS, к примеру, такой фичи просто нет. Совсем.
Так что забудьте вы уже про этот бред воспаленных мозгов бла-бла-архитектов, оно никому с адекватным восприятием реальности не нужно.
Здравствуйте, Somescout, Вы писали:
IT>>Вроде как код собираешься приводить ты, а не я. S>Вы б документацию к своему LinqToDB с таким же энтузиазмом пилили, как балаболили на форуме.
Здравствуйте, Ночной Смотрящий, Вы писали:
IT>>Я такое при возможности выкорчёвываю нещадно. НС>Только в случае использования asp.net core, и даже просто голого GenericHost1 уже все, выкорчевать ничего не выйдет, оно там прибито намертво гвоздями.
Мой самый первый пост был как раз об этом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>DI это и есть проект с сервис-локаторами и синглтонами, просто в несколько более запутанном виде.
Все-таки не совсем. В случае SL на вход принимается сам контейнер и далее через него получаются соотв.
типы. При DI мы получаем только нужны нам типы, про контейнер нам знать вообще не надо. Т.е. при SL
выпилить IoC контейнер будет сильно труднее, чем при DI.
и есть граф зависимостей: dbContext зависит от dbOptions, mainService зависит от dbContext и т.п. ·>Притом, если использовать исключительно Constructor Injection, то у тебя гарантированно получится DAG — а это круто с т.з. красивости архитектуры. ·>Только он нарисован вручную, в момент написания кода, а не автоматически сгенерирован в runtime.
Я именно про DAG, созданный в runtime. Т.е. помимо кода это где-то хранится(отражается) в памяти.
Здравствуйте, SkyDance, Вы писали:
SD>Создать объекты можно безо всяких там DI/IoС. SD>Как уже было замечено выше, "контейнер" (или composition root) — это способ назвать код "конфигурацией" и вынести его туда, где тестировать его становится сложно, а значит, (барабаны), не нужно.
Не до конца понимаю почему это плохо? Я сейчас уже IaC (infrastructure as a code) во всю, чем плоха
конфигурация как код? Тестирование -- это все-таки организационный вопрос, а не принципиальный.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>·>Мде уж. Это у тебя полная путаница. Основная фича DI — это отделить конструирование компонентов от их использования. S>>Без графа зависимостей этого не сделаешь? НС>Что именно не сделать без явного графа зависимостей?
Здравствуйте, Ночной Смотрящий, Вы писали:
VD>>По ходу ты не понимаешь того что лежит за DI. Основная фича DI — это расчет графа зависимостей и автоматическое создание объектов в последовательности зависимостей. НС>Нет. Основная фича DI контейнеров — управление созданием и уничтоженим экземпляров сервисов, и рантайм биндинг этих экземпляров к потребителям (слово injection в названии четко и недвусмысленно определяет что такое DI). Что то там рассчитывать на графе зависимостей — совершенно необязательная фича, которой может просто не быть.
А как узнать тогда кто и от чего зависит, что сделать инъекцию? Т.е. каков порядок создания объектов тогда,
без графа?
и есть граф зависимостей: dbContext зависит от dbOptions, mainService зависит от dbContext и т.п. S>·>Притом, если использовать исключительно Constructor Injection, то у тебя гарантированно получится DAG — а это круто с т.з. красивости архитектуры. S>·>Только он нарисован вручную, в момент написания кода, а не автоматически сгенерирован в runtime. S>Я именно про DAG, созданный в runtime. Т.е. помимо кода это где-то хранится(отражается) в памяти.
Всё равно я не понял вопрос "Без графа зависимостей этого не сделаешь?".
Если чё, объекты в памяти, которые ссылаются друг на друга и есть граф создаваемый и модифицируемый в runtime... DI тут непричём.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sharov, Вы писали:
VD>>>По ходу ты не понимаешь того что лежит за DI. Основная фича DI — это расчет графа зависимостей и автоматическое создание объектов в последовательности зависимостей. НС>>Нет. Основная фича DI контейнеров — управление созданием и уничтоженим экземпляров сервисов, и рантайм биндинг этих экземпляров к потребителям (слово injection в названии четко и недвусмысленно определяет что такое DI). Что то там рассчитывать на графе зависимостей — совершенно необязательная фича, которой может просто не быть. S>А как узнать тогда кто и от чего зависит, что сделать инъекцию?
По тому какие параметры в какой конструктор передаются.
S>Т.е. каков порядок создания объектов тогда, без графа?
В порядке исполения wiring-кода.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>Не до конца понимаю почему это плохо? Я сейчас уже IaC (infrastructure as a code) во всю, чем плоха S>конфигурация как код? Тестирование -- это все-таки организационный вопрос, а не принципиальный.
Потому что "организационную проблему" нельзя надежно решить раз и навсегда. Нельзя написать "организационный тест-кейс".
Код потому и переносят в конфигурацию, чтобы не тестировать.
AA>Это все хорошо, но только для небольших проектов, если проект сложный, то и способ сборки частей будет чуть хитрее чем простая передача экземпляра в конструктор.
В таком варианте — "способ сборки частей будет чуть хитрее" — тем более нельзя оставлять это на совести нетестируемого XML-файла в "конфигурации проекта".
Здравствуйте, Sharov, Вы писали:
S>Не до конца понимаю почему это плохо? Я сейчас уже IaC (infrastructure as a code) во всю, чем плоха S>конфигурация как код?
Тем что тут с точностью до наоборот, код как конфигурация.
Здравствуйте, Sharov, Вы писали:
НС>>DI это и есть проект с сервис-локаторами и синглтонами, просто в несколько более запутанном виде. S>Все-таки не совсем.
Все таки совсем. Внутри любого контейнера — service locator
S>При DI мы получаем только нужны нам типы, про контейнер нам знать вообще не надо.
Тем не менее внутри любого известного мне контейнера ссылки на service locator присутвуют в публичном API.
Если нам не помогут, то мы тоже никого не пощадим.
