А какой смысл мне наслаждаться этой ядовитостью невежества. Пусть все довольствуются ссылками на ссылки на миллион пустых статей о том, как внедрять корове седло гитфлоу. Кому надо, те на практике удостоверятся и сделают правильно, когда жизнь заставит, а остальные пусть играются в айтишку и делают что попало как хотят, это всё равно ни на что не влияет, можно разве что мамке похвастаться, что у них гитфлоу канбан кодефёрст и чёрт знает ещё какой мусор
Да, именно, что как сложилось так и погнали. Но проблема в том, что назвали это «гитфлоу» и ссылаемся на якобы методику при любых попытках что-то пересмореть. И да, заметна проблема не для всех. Но когда обстоятельства вынудят, тут окажется, что всё плохо и непонятно почему. Я хотел было написать ещё пару постов о том, что такое флоу в принципе, какие они бывают и почему, но вижу, что не стоит
«Как у всех» это когда ориентация не на то, какую проблему надо решать и как это делать правильно, а на то, «как там у всех». Все дают ссылки на эти статьи, в которых авторы сами не понимают, что они пишут.
6) Гораздо лучше показать свои рассуждения, пусть даже они не приведут к правильному ответу
Так не лить воду или показать свои рассуждения?
Кадровый подбор симптоматично показывает, что айтишка заполнена людьми, которые думают, что разобравшись в одном — автоматически разбираются во всём. Поэтому, например, карьерный трек в лиды у всех идёт через сеньоры, будто способность писать код автоматически делает тебя управленцем. Поэтому же люди с такой самоуверенностью лезут проводить собесы будто понимают, как это делать. Типичная история, когда тебе эйчар задаёт технические вопросы. Естественно ответы оценить не может и ищет просто знакомые буквы/слова. В крайнем случае запишет твои и искать их будут уже там какие-то эксперты. Всё это не имеет никакого отношения к оценке, это такая сложно и бессмысленно организованная бюрократическая угадайка, которая по качеству не отличается от её отсутствия (если не хуже), и просто отжирает время и треплет нервы.
Прежде всего не видел ни одного интервьера, который:
Отличал бы открытый вопрос от закрытого. Вопросы часто буквально как в меме про два стула. Люди просто не умеют спрашивать. Поэтому списывают вопросы друг у друга и находят в Гугле (но тебе-то запрещают читить, верно?).
Осознавал бы хоть в какой-то мере, что является критерием истины. Ибо типичная проблема — бессознательная ставка на «конвенциональную/авторитетную» теорию истины. Код на бумажке / в блокноте / в ворде — классический симптом.
Имел бы стратегию собеседования и пытался выяснить твои сильные стороны. Ибо незнание специалиста отличается от незнания прохожего. Специалист имея подготовку зарезолвит своё незнание за три минуты. Сюрприз: из этого и состоит его повседневная работа. Но люди сразу переходят к поиску слабых сторон, не зная, что это методологическая ошибка, ибо слабые стороны являются таковыми только на фоне сильных, а если ты сильных не знаешь, то не можешь оценить и слабых. И таким образом всё это просто декорированная подворотня, на которой до тебя докапываются разыгрывая сценки стендапов из Ютуба.
В подавляющем большинстве случаев люди не разбираются в кадровом подборе и если уж начинать с ошибок, то первая — непризнание этого факта. Не берись за дело, в котором не разбираешься.
В большинстве случаев методики найма равносильны их отсутствию: бери любого. Ибо всю главную работу кандидат уже сделал сам — он тебя нашёл по твоим критериям и готов за них отвечать. Если ты ему предоставишь возможность, то в подавляющем большинстве случаев он свой отклик оправдает (если конечно у тебя не колхоз в компании). Но только без этого цирка с конями.
Я закрыл ишу на Гитхабе. К сожалению удалить свой пост на Хабре не могу. Предлагаю взять себя в руки и проигнорировать его. Мало ли какие дурачки добрались до Хабра и пишут что попало, не обращайте внимания.
Не было никакой бизнес проблемы, я пример выдумал для демонстрации и не скрывал этого. Это Вы сами решили, что я сюда за костылями пришёл. Я сюда принёс предложение, которое Вы не поняли, а завалили комментарии своим желанием кого-то покритиковать толком ни в чём не разобравшись.
Вы не удосужились вчитаться, не поняли проблему. А вот разработчик из Майкрософт её понял и предложил вариант решения. Пойдите почитайте ишу и комментарии к ней на Гитхабе.
Рецептов много, далеко не все они хороши. Код от просто текста конечно отличает именно то, что он работает. Но мы заботимся об архитектуре потому что этого недостаточно. Нужно писать такой код, который был бы максимально производителен, удобен в развитии и не допускал бы по каждой правке переписывания половины проекта. Именно поэтому мы делим всё на хорошие и плохие практики.
По ссылке на ишу в гитхабе можно почитать обсуждение. Там разработчик Майкрософт предложил вместо провайдера вариант экстеншна, который делает то, что надо. Я ему предложил добавить свой экстеншн в нюгет пакет контейнера, поскольку это относится к апи контейнера. Но он не ответил больше. Я сомневаюсь, что это сделают. Хотя ишу не закрыли пока, она чего-то ждёт.
Так что можно считать его экстеншн как наилучшую из имеющихся сейчас практик для подобного рода сценариев регистрации зависимостей. Чтобы поменьше было костылей с правками во всех контроллерах. Правда его решение доступно только в новой версии пакета, потому что основано на именованных зависимостях. Но это лучше, чем ничем ничего
Можно, почему нет. Только при такой постановке вопроса можно вообще что-то написать без контейнера, или переделать архитектуру разделив сервисы на разные приложения. Но это просто другая тема.
Пример я придумал чтобы продемонстрировать проблему именно контейнера зависимостей. Его можно развивать дальше. Заказчик может менять требования каждый день. Это вполне правдоподобно, так как это может не от него зависеть, ибо распределённые большие системы отданные на аутсорс могут порождать подобные требования через посредников внезапно и часто, и времени на их реализацию выделять мало. И понять заказчиков можно, они же не обязаны знать несовершенство чьей-то архитектуры, для них это простой вопрос трёх заказанных ими сервисов и разделения трафика логов по ним. А завтра заказчик ещё придумает нечто подобное. Каждый раз архитектуру менять?
Так что это не вопрос переменных окружения. Это вопрос отсутствия возможностей управления полиморфизмом в контейнере зависимостей.
Кажется это условие прописывается по статичным критериям, например значения конфига. Это можно сделать и сейчас, определив делегат, в котором написать сколь угодно сложную логику вариативности, только она не привязана к потребителю зависимости, она будет отдавать всем контроллерам нечто одно.
Мне кажется я подобрал вполне правдоподобный и показательный пример с контроллерами, на котором сразу заметно, что работает, а что нет.
Выше кто-то предлагал уже решить это через особую регистрацию контроллеров, то есть изначально зарегистрировать 50 контроллеров с одной имплементацией, 50 с другой и 50 с третьей. Это наилучшая пока идея в текущих условиях без переделки контейнера.
Я предложил новый интерфейс, хотя не уверен в оптимальности предложения. Но даже при таком варианте в общем случае для разработчика ничего не поменяется, как были зарегистрированы зависимости так и остались. Но теперь можно конкретному контракту положить не его имплементацию, а провайдера. А в самом контейнере нужно добавить условие: если запрошенная зависимость это провайдер, то делегировать резолвинг ему. И собственно всё.
А провайдере должно быть всё необходимое: сам контейнер с сервисами в нём, но ещё и пришедший в аргументе критерий, по которому можно сделать вариативность резолвинга.
Это точечный механизм не затрагивающий общую ситуацию. Но только в том случае, если в самом контейнере это условие с передачей типа предъявителя есть. То есть нельзя это реализовать без переделки самого контейнера.
А предъявитель всегда известен, ибо в любой момент времени где бы то ни было кто-то же вызывает метод получения какого-то сервиса из контейнера — вот пусть передаёт не только то, что хочет получить, но и дополнительно сообщает, кто он такой.
Таких сценариев в общем случае два:
автоматический, типа как с контроллерами
и ручной, когда мы сами пишем какую-то логику с запросом каких-то зависимостей.
Можно сделать критерий налабл типа и тогда его можно не передавать потому что по дефолту будет null, а провайдер тогда отдаст дефолтную имплементацию.
Как резолвить конкретно в провайдере вопрос широких возможностей. Какую-то наивную простую версию того, как бы это могло быть, я привёл по ссылке в ишу на Гитхабе. Но пока не будет понята сама идея, все предложения будут не оптимальны и как показывает дискуссия в комментариях, всё будет сводиться к изобретению очередного лайвхака. Я же предлагаю поменять сам механизм в целом.
Я не могу предложить пул-реквест в язык, потому что недостаточно просто что-то написать, чтобы работало, там же множество правил, которые я не знаю, планы релизного цикла, какие-то конвенции явные и неявные. У Майкрософт плохая привычка изобретать кучу спецификаций на ровном месте и поэтому недостаточно знать сишарп, чтобы это написать. Вы заглядывали в исходники? Там же через эмит рефлексию на их высокоуровневом ассемблере дописано для производительности. Под капотом используется куча технологий и правила использования каждой знать надо. Это не просто.
Поэтому эту идею нужно осмыслить авторам и найти оптимальный вариант реализации. На мой взгляд сделать новый интерфейс и дописать под него сценарий проверки и делегирования с передачей типа предъявителя — это наименее болезненный вариант. Но возможно есть варианты получше. Прежде всего надо понять саму идею. Я допускаю, что у неё есть слабые стороны, которые её обнуляют. Но пока я их не вижу.
Если бы Вы не отклонялись от предложенного мною примера, то наверное бы всё поняли.
Никакой контейнер не реализует эту возможность. Предложение реализовать свой конечно всегда выглядит солидно, только для него не нужна компетенция, его достаточно заучить и приходить в любую дискуссию дежурно вбрасывая предложение изобрести свой интернет. Ценность такого предложения равна нулю. Можно было просто пройти мимо моей заметки, если Вам она показалась глупой.
Я не просил решения, я знаю, что их существует много. Я описал и пример, и проблему, и решение. А множество рецептов Вам никто не запрещает использовать.
Вы не понимаете проблему. `IServiceProvider.GetService(Type serviceType)` это запрос имплементации по указанному типу его контракта. Вы указываете, что хотите получить и получаете объект этого. Ваш код отдаёт разные клиенты потому что запрашиваются разные клиенты, он и написан в расчёте на это. А как Вы будете в контроллерах запрашивать разные? Вы пойдёте их все перепишите и укажите в каком какой отдавать. Хотя казалось бы, все кругом говорят о инверсии зависимостей, дескать зависеть надо от абстракций и в потребителях Ваших должны быть указаны интерфейсы, а как они резолвятся и что приходит в итоге это не важно, если оно соблюдает контракт. Но Вы не можете поставить абстракцию без дополнительного огорода получения её конкретной имплементации.
Я никого не хочу обидеть, но на мой взгляд в этом виноваты прежде всего Майкрософт, потому что они мало того, что за столько лет не могли ничего придумать, но по сути своим добавлением именованных сервисов легализовали костыли и сделали их нормой жизни. А теперь все спорят и доказывают, что это нормально. Это не нормально. Потому что мне проще тогда поставить в контроллерах явное указание конкретного логера забив на принцип инверсии зависимостей, ибо DI контейнер не предоставляет мне такую возможность. Собственно все как-то и живут с этим, городят огороды и всё это работает. Но это не значит, что это нормально. Во всяком случае я не собирался переубеждать тех, кому это нравится. Я предложил дополнение к самой концепции контейнера внедрения зависимостей, которая просто исключает всё это пространство лайфхаков.
Смотря что считать проблемой. Я написал, что не решают. Но мы все как-то живём и что-то пишем, как-то выкручиваемся. Именованные сервисы это разочарование. Майкрософт сделало нормальным очередную плохую практику. Проще указать в зависимостях тогда конкретный файловый логер, например, чем городить какой-то ключ, который указывает то же самое.
Идея в том, чтобы дополнить принцип действия контейнера таким механизмом, чтобы всегда передавать предъявителя запроса и таким образом можно забыть про костыли. Проблема не только сишарповская. Я точно знаю, что есть такая же в php на Laravel, потому что там контейнер работает так же.
В небольших масштабах проблема не заметна. Или в других условиях, например на микросервисной архитектуре, где все эти сервисы разделены по разным по сути приложениям. Конечно эту проблему можно решить разными способами. Но какие бывают велосипеды — это другой вопрос. Здесь же я просто подумав нашёл способ дополнить сам контейнер таким свойством, которое позволяет вообще не писать эти велосипеды. Прежде всего это дополнение самой концепции контейнера внедрения зависимостей.
Вы значит просто не поняли, в чём суть проблемы и предложения. Попробуйте применить это к описанному примеру и убедитесь, что у Вас нет способа определить в этой фабрике, кому какую имплементацию отдать.
Показательный уровень аудитории, не читал, но осуждаешь. Иди мамке похвастайся, великое дело сделал.
А какой смысл мне наслаждаться этой ядовитостью невежества. Пусть все довольствуются ссылками на ссылки на миллион пустых статей о том, как внедрять
корове седлогитфлоу. Кому надо, те на практике удостоверятся и сделают правильно, когда жизнь заставит, а остальные пусть играются в айтишку и делают что попало как хотят, это всё равно ни на что не влияет, можно разве что мамке похвастаться, что у них гитфлоу канбан кодефёрст и чёрт знает ещё какой мусорДа, именно, что как сложилось так и погнали. Но проблема в том, что назвали это «гитфлоу» и ссылаемся на якобы методику при любых попытках что-то пересмореть. И да, заметна проблема не для всех. Но когда обстоятельства вынудят, тут окажется, что всё плохо и непонятно почему. Я хотел было написать ещё пару постов о том, что такое флоу в принципе, какие они бывают и почему, но вижу, что не стоит
Ну, это другая тема, конечно. Могу только посочувствовать. Благо сейчас у нас есть выбор: gitflic.ru, gitverse.ru, sourcecraft.dev.
«Как у всех» это когда ориентация не на то, какую проблему надо решать и как это делать правильно, а на то, «как там у всех». Все дают ссылки на эти статьи, в которых авторы сами не понимают, что они пишут.
Так не лить воду или показать свои рассуждения?
Кадровый подбор симптоматично показывает, что айтишка заполнена людьми, которые думают, что разобравшись в одном — автоматически разбираются во всём. Поэтому, например, карьерный трек в лиды у всех идёт через сеньоры, будто способность писать код автоматически делает тебя управленцем. Поэтому же люди с такой самоуверенностью лезут проводить собесы будто понимают, как это делать. Типичная история, когда тебе эйчар задаёт технические вопросы. Естественно ответы оценить не может и ищет просто знакомые буквы/слова. В крайнем случае запишет твои и искать их будут уже там какие-то эксперты. Всё это не имеет никакого отношения к оценке, это такая сложно и бессмысленно организованная бюрократическая угадайка, которая по качеству не отличается от её отсутствия (если не хуже), и просто отжирает время и треплет нервы.
Прежде всего не видел ни одного интервьера, который:
Отличал бы открытый вопрос от закрытого. Вопросы часто буквально как в меме про два стула. Люди просто не умеют спрашивать. Поэтому списывают вопросы друг у друга и находят в Гугле (но тебе-то запрещают читить, верно?).
Осознавал бы хоть в какой-то мере, что является критерием истины. Ибо типичная проблема — бессознательная ставка на «конвенциональную/авторитетную» теорию истины. Код на бумажке / в блокноте / в ворде — классический симптом.
Имел бы стратегию собеседования и пытался выяснить твои сильные стороны. Ибо незнание специалиста отличается от незнания прохожего. Специалист имея подготовку зарезолвит своё незнание за три минуты. Сюрприз: из этого и состоит его повседневная работа. Но люди сразу переходят к поиску слабых сторон, не зная, что это методологическая ошибка, ибо слабые стороны являются таковыми только на фоне сильных, а если ты сильных не знаешь, то не можешь оценить и слабых. И таким образом всё это просто декорированная подворотня, на которой до тебя докапываются разыгрывая сценки стендапов из Ютуба.
В подавляющем большинстве случаев люди не разбираются в кадровом подборе и если уж начинать с ошибок, то первая — непризнание этого факта. Не берись за дело, в котором не разбираешься.
В большинстве случаев методики найма равносильны их отсутствию: бери любого. Ибо всю главную работу кандидат уже сделал сам — он тебя нашёл по твоим критериям и готов за них отвечать. Если ты ему предоставишь возможность, то в подавляющем большинстве случаев он свой отклик оправдает (если конечно у тебя не колхоз в компании). Но только без этого цирка с конями.
Я закрыл ишу на Гитхабе. К сожалению удалить свой пост на Хабре не могу. Предлагаю взять себя в руки и проигнорировать его. Мало ли какие дурачки добрались до Хабра и пишут что попало, не обращайте внимания.
Не было никакой бизнес проблемы, я пример выдумал для демонстрации и не скрывал этого. Это Вы сами решили, что я сюда за костылями пришёл. Я сюда принёс предложение, которое Вы не поняли, а завалили комментарии своим желанием кого-то покритиковать толком ни в чём не разобравшись.
Вы не удосужились вчитаться, не поняли проблему. А вот разработчик из Майкрософт её понял и предложил вариант решения. Пойдите почитайте ишу и комментарии к ней на Гитхабе.
Рецептов много, далеко не все они хороши. Код от просто текста конечно отличает именно то, что он работает. Но мы заботимся об архитектуре потому что этого недостаточно. Нужно писать такой код, который был бы максимально производителен, удобен в развитии и не допускал бы по каждой правке переписывания половины проекта. Именно поэтому мы делим всё на хорошие и плохие практики.
По ссылке на ишу в гитхабе можно почитать обсуждение. Там разработчик Майкрософт предложил вместо провайдера вариант экстеншна, который делает то, что надо. Я ему предложил добавить свой экстеншн в нюгет пакет контейнера, поскольку это относится к апи контейнера. Но он не ответил больше. Я сомневаюсь, что это сделают. Хотя ишу не закрыли пока, она чего-то ждёт.
Так что можно считать его экстеншн как наилучшую из имеющихся сейчас практик для подобного рода сценариев регистрации зависимостей. Чтобы поменьше было костылей с правками во всех контроллерах. Правда его решение доступно только в новой версии пакета, потому что основано на именованных зависимостях. Но это лучше, чем ничем ничего
Можно, почему нет. Только при такой постановке вопроса можно вообще что-то написать без контейнера, или переделать архитектуру разделив сервисы на разные приложения. Но это просто другая тема.
Пример я придумал чтобы продемонстрировать проблему именно контейнера зависимостей. Его можно развивать дальше. Заказчик может менять требования каждый день. Это вполне правдоподобно, так как это может не от него зависеть, ибо распределённые большие системы отданные на аутсорс могут порождать подобные требования через посредников внезапно и часто, и времени на их реализацию выделять мало. И понять заказчиков можно, они же не обязаны знать несовершенство чьей-то архитектуры, для них это простой вопрос трёх заказанных ими сервисов и разделения трафика логов по ним. А завтра заказчик ещё придумает нечто подобное. Каждый раз архитектуру менять?
Так что это не вопрос переменных окружения. Это вопрос отсутствия возможностей управления полиморфизмом в контейнере зависимостей.
Это лучшая пока идея в текущих условиях
Кажется это условие прописывается по статичным критериям, например значения конфига. Это можно сделать и сейчас, определив делегат, в котором написать сколь угодно сложную логику вариативности, только она не привязана к потребителю зависимости, она будет отдавать всем контроллерам нечто одно.
Мне кажется я подобрал вполне правдоподобный и показательный пример с контроллерами, на котором сразу заметно, что работает, а что нет.
Выше кто-то предлагал уже решить это через особую регистрацию контроллеров, то есть изначально зарегистрировать 50 контроллеров с одной имплементацией, 50 с другой и 50 с третьей. Это наилучшая пока идея в текущих условиях без переделки контейнера.
Я предложил новый интерфейс, хотя не уверен в оптимальности предложения. Но даже при таком варианте в общем случае для разработчика ничего не поменяется, как были зарегистрированы зависимости так и остались. Но теперь можно конкретному контракту положить не его имплементацию, а провайдера. А в самом контейнере нужно добавить условие: если запрошенная зависимость это провайдер, то делегировать резолвинг ему. И собственно всё.
А провайдере должно быть всё необходимое: сам контейнер с сервисами в нём, но ещё и пришедший в аргументе критерий, по которому можно сделать вариативность резолвинга.
Это точечный механизм не затрагивающий общую ситуацию. Но только в том случае, если в самом контейнере это условие с передачей типа предъявителя есть. То есть нельзя это реализовать без переделки самого контейнера.
А предъявитель всегда известен, ибо в любой момент времени где бы то ни было кто-то же вызывает метод получения какого-то сервиса из контейнера — вот пусть передаёт не только то, что хочет получить, но и дополнительно сообщает, кто он такой.
Таких сценариев в общем случае два:
автоматический, типа как с контроллерами
и ручной, когда мы сами пишем какую-то логику с запросом каких-то зависимостей.
Можно сделать критерий налабл типа и тогда его можно не передавать потому что по дефолту будет null, а провайдер тогда отдаст дефолтную имплементацию.
Как резолвить конкретно в провайдере вопрос широких возможностей. Какую-то наивную простую версию того, как бы это могло быть, я привёл по ссылке в ишу на Гитхабе. Но пока не будет понята сама идея, все предложения будут не оптимальны и как показывает дискуссия в комментариях, всё будет сводиться к изобретению очередного лайвхака. Я же предлагаю поменять сам механизм в целом.
Я не могу предложить пул-реквест в язык, потому что недостаточно просто что-то написать, чтобы работало, там же множество правил, которые я не знаю, планы релизного цикла, какие-то конвенции явные и неявные. У Майкрософт плохая привычка изобретать кучу спецификаций на ровном месте и поэтому недостаточно знать сишарп, чтобы это написать. Вы заглядывали в исходники? Там же через эмит рефлексию на их высокоуровневом ассемблере дописано для производительности. Под капотом используется куча технологий и правила использования каждой знать надо. Это не просто.
Поэтому эту идею нужно осмыслить авторам и найти оптимальный вариант реализации. На мой взгляд сделать новый интерфейс и дописать под него сценарий проверки и делегирования с передачей типа предъявителя — это наименее болезненный вариант. Но возможно есть варианты получше. Прежде всего надо понять саму идею. Я допускаю, что у неё есть слабые стороны, которые её обнуляют. Но пока я их не вижу.
Если бы Вы не отклонялись от предложенного мною примера, то наверное бы всё поняли.
Никакой контейнер не реализует эту возможность. Предложение реализовать свой конечно всегда выглядит солидно, только для него не нужна компетенция, его достаточно заучить и приходить в любую дискуссию дежурно вбрасывая предложение изобрести свой интернет. Ценность такого предложения равна нулю. Можно было просто пройти мимо моей заметки, если Вам она показалась глупой.
Я не просил решения, я знаю, что их существует много. Я описал и пример, и проблему, и решение. А множество рецептов Вам никто не запрещает использовать.
Вы не понимаете проблему. `IServiceProvider.GetService(Type serviceType)` это запрос имплементации по указанному типу его контракта. Вы указываете, что хотите получить и получаете объект этого. Ваш код отдаёт разные клиенты потому что запрашиваются разные клиенты, он и написан в расчёте на это. А как Вы будете в контроллерах запрашивать разные? Вы пойдёте их все перепишите и укажите в каком какой отдавать. Хотя казалось бы, все кругом говорят о инверсии зависимостей, дескать зависеть надо от абстракций и в потребителях Ваших должны быть указаны интерфейсы, а как они резолвятся и что приходит в итоге это не важно, если оно соблюдает контракт. Но Вы не можете поставить абстракцию без дополнительного огорода получения её конкретной имплементации.
Я никого не хочу обидеть, но на мой взгляд в этом виноваты прежде всего Майкрософт, потому что они мало того, что за столько лет не могли ничего придумать, но по сути своим добавлением именованных сервисов легализовали костыли и сделали их нормой жизни. А теперь все спорят и доказывают, что это нормально. Это не нормально. Потому что мне проще тогда поставить в контроллерах явное указание конкретного логера забив на принцип инверсии зависимостей, ибо DI контейнер не предоставляет мне такую возможность. Собственно все как-то и живут с этим, городят огороды и всё это работает. Но это не значит, что это нормально. Во всяком случае я не собирался переубеждать тех, кому это нравится. Я предложил дополнение к самой концепции контейнера внедрения зависимостей, которая просто исключает всё это пространство лайфхаков.
Смотря что считать проблемой. Я написал, что не решают. Но мы все как-то живём и что-то пишем, как-то выкручиваемся. Именованные сервисы это разочарование. Майкрософт сделало нормальным очередную плохую практику. Проще указать в зависимостях тогда конкретный файловый логер, например, чем городить какой-то ключ, который указывает то же самое.
Идея в том, чтобы дополнить принцип действия контейнера таким механизмом, чтобы всегда передавать предъявителя запроса и таким образом можно забыть про костыли. Проблема не только сишарповская. Я точно знаю, что есть такая же в php на Laravel, потому что там контейнер работает так же.
В небольших масштабах проблема не заметна. Или в других условиях, например на микросервисной архитектуре, где все эти сервисы разделены по разным по сути приложениям. Конечно эту проблему можно решить разными способами. Но какие бывают велосипеды — это другой вопрос. Здесь же я просто подумав нашёл способ дополнить сам контейнер таким свойством, которое позволяет вообще не писать эти велосипеды. Прежде всего это дополнение самой концепции контейнера внедрения зависимостей.
Да, всё верно, в этом и проблема
Вы значит просто не поняли, в чём суть проблемы и предложения. Попробуйте применить это к описанному примеру и убедитесь, что у Вас нет способа определить в этой фабрике, кому какую имплементацию отдать.