Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Суть меняется в том смысле, что таки да, контейнер позволяет писать по старинке НС>Суть в том, что локатор как таковой никоим образом не детерминирует способ получения сервиса. Метод ли это Resolve или DI — локатор не перестает быть локатором.
Непонятно. SL подразумевает, что оттуда что-то можно получить, т.е. Resolve тебе найдёт что надо и выдаст. В то время DI же ничего не получает, ему всё дают. Как используя DI можно что-то получить? Это противоположные вещи.
Ты видимо путаешь Locator, Injector, контейнер.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinclair, Вы писали:
S>Компилятор бъёт его по рукам, потому что получившийся DAG не сводится к дереву.
Чуть поправлю: "получившийся граф не сводится к DAG, т.к. содержит цикл". Деревья тут непричём.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sinclair, Вы писали:
S>А когда мы полагаемся на "уолшебный контейнер", то обнаружение кольцевой зависимости откладывается до рантайма. Поэтому такой код можно прекрасно закоммитить в репозиторий; и он даже может ездить в продакшне — до тех пор, пока кто-то не попытается активировать сервис доставки при помощи конфигурации.
Ещё добавлю. Дело не только в циклах, но и в элементарном разрешении зависимостей.
if(A) then add(DeliveryService)
if(B) then add(PigeonTransportService)
И отсюда ты фиг узнаешь, что на самом деле кто-то добавил в DeliveryService зависимость от PigeonTransportService и теперь от верности условий A и B у нас что-то будет падать, что-то не будет и очень хороший шанс, что обнаружится это только в проде. Тогда как при ручном описании — эта проблема станет заметна уже в IDE.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Непонятно. SL подразумевает, что оттуда что-то можно получить, т.е. Resolve тебе найдёт что надо и выдаст. В то время DI же ничего не получает, ему всё дают.
Ты зарплату не получаешь, ее тебе дают? К чему эта софистика?
·> Как используя DI можно что-то получить?
Объявить параметр в конструкторе.
·> Это противоположные вещи.
Нет.
·>Ты видимо путаешь Locator, Injector, контейнер.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Непонятно. SL подразумевает, что оттуда что-то можно получить, т.е. Resolve тебе найдёт что надо и выдаст. В то время DI же ничего не получает, ему всё дают. НС>Ты зарплату не получаешь, ее тебе дают?
Вот это софистика.
НС>К чему эта софистика?
Это ключевое слово: Inversion of Control.
НС>·> Как используя DI можно что-то получить? НС>Объявить параметр в конструкторе.
Параметр объявляет тип, а инжектится инстанс. И соотвественно в случае SL надо вызывать Resolve для того чтобы получить инстанс для данного типа.
В динамических языках, где все типы "object" — такой вопрос о типах стоять не будет, а SL/DI таки будут различаться.
НС>·> Это противоположные вещи. НС>Нет.
Это твоё личное понимание. Общепринятое понятие — я тебе уже приводил цитату
DI directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
НС>>К чему эта софистика? ·>Это ключевое слово: Inversion of Control.
Нет такого ключевого слова в определении service locator. Ты упорно пытаешься смешать две разные вещи.
НС>>·> Как используя DI можно что-то получить? НС>>Объявить параметр в конструкторе. ·>Параметр объявляет тип, а инжектится инстанс.
И? При вызове Resolve указывается тип, а возвращает он инстанс.
·> И соотвественно в случае SL надо вызывать Resolve для того чтобы получить инстанс для данного типа.
Нет такого в определении service locator.
·>В динамических языках, где все типы "object"
Здравствуйте, ·, Вы писали: S>>Компилятор бъёт его по рукам, потому что получившийся DAG не сводится к дереву. ·>Чуть поправлю: "получившийся граф не сводится к DAG, т.к. содержит цикл". Деревья тут непричём.
Да, это я в запарке написал. Имел в виду именно то, что вы поправили.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>К чему эта софистика? НС>·>Это ключевое слово: Inversion of Control. НС>Нет такого ключевого слова в определении service locator. Ты упорно пытаешься смешать две разные вещи.
Like Dependency Injection, the Service Locator Pattern allows dependencies to be defined externally and apart from the application logic. But rather than injecting, these dependencies are made available upon request by the application.
и т.д. https://www.c2experience.com/blog/inversion-of-control-using-an-injectable-service-locator
НС>>>·> Как используя DI можно что-то получить? НС>>>Объявить параметр в конструкторе. НС>·>Параметр объявляет тип, а инжектится инстанс. НС>И? При вызове Resolve указывается тип, а возвращает он инстанс.
Типы тут вообще непричём. Можно делать даже так если нет генериков:
НС>·> И соотвественно в случае SL надо вызывать Resolve для того чтобы получить инстанс для данного типа. НС>Нет такого в определении service locator.
"...on request returns the information necessary..."
НС>·>В динамических языках, где все типы "object" НС>При чем тут динамические языки?
Притом что типы к DI/SL прямого отношения не имеют.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Параметр объявляет тип, а инжектится инстанс. НС>>И? При вызове Resolve указывается тип, а возвращает он инстанс. ·>Типы тут вообще непричём.
Здравствуйте, Министр Промышленности, Вы писали:
МП>С моей профессиональной точки зрения DI фреймворки не нужны.
МП>Они затрудняют распутывание кода, МП>понижают гибкость автоматического рефакторинга (в частности ReSharper-ом) МП>и это не перекрывается гибкостью подстановки mock-объектов
МП>но обнаруживаю ярых адептов этого всего. МП>уже и в вакансиях суют такое требование
МП>кто-то может популярно расписать преимущества либо природу явления популярности? МП>(часть плюсов знаю и гипотезы-то я имею, но мнение всё равно такое)
А как же это?
Несмотря на то, что я использую Poor man's DI для исследования и объяснения механизма внедрения зависимостей,
я не рекомендую использовать его для профессионального использования.
Многие отличные DI-контейнеры доступны на .NET и все они являются бесплатными.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тебе тогда тот же вопрос. Какая обязательная фича DI контейнеров требует " расчет графа зависимостей"?
А ты попробуй представить упрощенный алгоритм создания экземпляра класса. Вот есть у тебя классы A, B и C. Они зависят один от другого. Скажем C от B и B от A. Как создать C? Сначала придется создать A и Б. Далее добауляем сюда регистпацию. И вот она проблема. Регистрация может произойти после создания регистрируемого типа. Если бы рассчет.зависимостей и регистрация происходили во время компиляции, этой проблемы не было бы, а все резолвы могла бы показать IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А ты попробуй представить упрощенный алгоритм создания экземпляра класса.
Влад, мне не надо его представлять, я сам парочку контейнеров написал, и код MS.DependencyInjection очень хорошо знаю.
VD> Вот есть у тебя классы A, B и C. Они зависят один от другого. Скажем C от B и B от A. Как создать C? Сначала придется создать A и Б.
И? Граф то зачем?
Я тебе больше скажу, в случае штатного контейнера дотнета его в принципе создать нельзя. Возьмем такой метод:
public static IServiceCollection AddSingleton (this IServiceCollection services, Type serviceType, Func<IServiceProvider,object> implementationFactory);
Как ты тут зависимости определишь? Будешь IL код анализировать?
VD> Далее добауляем сюда регистпацию. И вот она проблема. Регистрация может произойти после создания регистрируемого типа.
В случае штатной реализации дотнета — не может. Регистрируешь ты в IServiceCollection, а экземпляры создает IServiceProvider.
VD> Если бы рассчет.зависимостей и регистрация происходили во время компиляции, этой проблемы не было бы
Ее и так нет.
VD>, а все резолвы могла бы показать IDE.
Здравствуйте, IT, Вы писали:
IT>Документацию см. здесь.
Я вижу у вас она так и осталась таким же г, как и была пару лет назад — фактически Hello World ORM.
IT>Слив защитан.
Да плевать как-то. Я готов дискутировать (и приводить примеры кода) с коллегой, который тоже не чурается приводить примеры своих мыслей в коде. Но извините, вы мне не начальник и не преподаватель чтобы надув щёки что-то от меня требовать. Не хотите сами раскрывать свои мысли — идите лесом. И подальше.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>И? Граф то зачем?
Он сам собой получается. Зависимости формально описываются направленным ациклическим графом. Если есть циклы такие зависимости уже и создать то нельзя, точнее нужно специально вместе создавать.
НС>Как ты тут зависимости определишь? Будешь IL код анализировать?
Тут ты будешь этот код вручную описывать. Сначала создаешь сервис A, затем B, и затем C. И именно по этому такими DI пользоваться крайне неудобно и это прошлый век. Да они DI и не зовутся. Такое сервис-провайдерами называют. В VS от этого, например, давно ушли и перешли на MEF.
НС>В случае штатной реализации дотнета — не может. Регистрируешь ты в IServiceCollection, а экземпляры создает IServiceProvider.
Не "не можешь", а "полностью ложится на плечи программиста". Это вообще худшее из того что можно придумать. Таким подходом пользовались на заре компонентной архитектуры. В VS 2005, например. Тут управление зависимостями полностью ложится на тебя и, как следствие, то и дело прут ошибки когда одни сервис требует другой, а тот еще не загружен. Вот эти вот фабричные методы "implementationFactory" нужны для того, чтобы отложить создание на как можно более поздний срок. Но оно все равно стреляет. И в реальности оно выливается в Ад. Проверено на тех же студийных плагинах.
Именно по этому новые поколения стали управлять созданием зависимостей. Но и это взывает проблемы, если все делается динамически. А вот статический вариант решает большинство проблем, не создавая дополнительных. Но он сложен в реализации и поддержании по тому на сегодня практически не используется.
НС>Ее и так нет.
Есть и не в теории, а постоянно на практике вылезают. Вопрос лишь в объемах кода и числе разработчиков работающих над проектом.
НС>Что значит показать резолвы?
То и значит. 99% можно просчитывать статически. Ловить циклы. Показывать тот самый DAG зависимостей явно и ходить по нему. Математика вместо динамики.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Он сам собой получается.
О как. Только что рассчет графа был главной функцией, а теперь уже сам собой.
НС>>Как ты тут зависимости определишь? Будешь IL код анализировать? VD>Тут ты будешь этот код вручную описывать. Сначала создаешь сервис A, затем B, и затем C. И именно по этому такими DI пользоваться крайне неудобно и это прошлый век.
Это дотнетный родной, и он весьма свежий. И, разумеется, это не единственный вариант метода. Есть и другие, без фабрик. Но этот вариант наглядно демонстрирует что полного графа в любом случае построить нельзя. Что, при заявленной главной функции именно в построении графа выглядит крайне странно, не находишь?
VD> Да они DI и не зовутся.
Зовется оно Microsoft.DependencyInjection
НС>>В случае штатной реализации дотнета — не может. Регистрируешь ты в IServiceCollection, а экземпляры создает IServiceProvider. VD>Не "не можешь", а "полностью ложится на плечи программиста".
Именно не можешь. Нельзя ничего зарегистрировать после сборки контейнера.
VD>Вот эти вот фабричные методы "implementationFactory"
Ты опять читаешь по диагонали, теряя смысл.
VD>Именно по этому новые поколения стали управлять созданием зависимостей. Но и это взывает проблемы, если все делается динамически. А вот статический вариант
Статический вариант уже есть, это отказ от DI.
VD> решает большинство проблем, не создавая дополнительных.
Так какую проблему решает построение графа зависимостей?
НС>>Ее и так нет. VD>Есть и не в теории, а постоянно на практике вылезают. Вопрос лишь в объемах кода и числе разработчиков работающих над проектом.
Приведи пример вылезшей на практике необходимости построить граф зависимостей.
НС>>Что значит показать резолвы? VD>То и значит. 99% можно просчитывать статически.
Посчитать статически чего?
VD>Ловить циклы.
Как показывает практика, мни минимальном соблюдении несложных принципов дизайна циклы вообще не являются проблемой. Если единственное для чего нужен DI контейнер это ловить циклы, то он вообще не нужен.
Здравствуйте, VladD2, Вы писали:
VD>Подумай на досуге, как можно создавать сервисы не зная о их зависимостях и порядке создания.
Это просто. "Отказ от зависимости" и переход к "функциональной композиции".
Марк Земанн (автор DI) как раз сейчас проповедует "отказ" https://blog.ploeh.dk/2017/02/02/dependency-rejection/.
Правда для этого необходим соответствующий ЯП, наверно.
Еще в статье заметно, что частичное применение это то же DI только в ФП стиле.
В том же CL его вообще нет. Хотя штука может и удобная. Но коварная.
А вот композиция позволяет не думать о порядке, т.к. порядок задан явно.
