Разрабатывается библиотека, на C#
Библиотека предоставляет два публичных интерфейса, Interface1 и Interface2.
Классы, что реализуют Interface1 и Interface2, используют DI для получения ряда данных, таких, например, как конфигурация.
В классе, который реализует Interface2, нужно создать экземпляр класса, реализующего Interface1,
снаружи этот экземпляр и его методы не видны.

Я думаю — нужно ли в этом месте поддержать DI, чтобы создавать не класс, а то что зарегистрировано в DI?
Как-то мне кажется что DI внутри вообще не нужен. А если кто переопределил через DI реализацию Interface1, но не переопределил Interface2 — то ошибка.

Насколько это логично?

Здравствуйте, andsm, Вы писали:

A>Классы, что реализуют Interface1 и Interface2, используют DI для получения ряда данных, таких, например, как конфигурация.
В этот момент библиотека перестает быть библиотекой и становится, в лучшем случае, модулем фреймоворка. А в худшем случае она становится частью шаблона сервиса (service template), которая по недоразумению оказалась в общей библиотеке.

A>Я думаю — нужно ли в этом месте поддержать DI, чтобы создавать не класс, а то что зарегистрировано в DI?
Нужно разделять функциональность, предоставляемую библиотекой и способы, которыми библиотека конфигурируется. В библиотеке можно сделать несколько фабричных методов для Interface2. Один получает Interface1 в качестве одного из параметров. Другой не получает и создает Interface1 сам внутри. Если очень хочется, можно написать второй модуль (библиотеку) для DI. Он будет иметь зависимость на библиотеку и предоставлять фабрики для DI. Вот уже в нем можно описать конкретные условия и конфигурацию. Этот модуль строго опционален. Если вдруг команда хочет переиспользовать Interface1 для вас и где-то в своем коде, она может написать свою конфигурацию для DI. Вроде бы такие в spring boot подобные библиотеки называются активаторами (activator). А даже если и не называются, мне кажется, что название очень подходит.

A>Как-то мне кажется что DI внутри вообще не нужен.
Внутри основной библиотеки — не нужен. Для клиентов — зависит от вашей точки зрения. Я считаю, что не нужен. Я бы внес создание/конфигурирование вашего сервиса в общий шаблон (service template) и на этом остановился. Шаблон используется для новых сервисов, там была бы какая-то условно-рабочая конфигурация. Она копируется в код сервиса, поэтому разработчики легко смогут найти и изменить ее. Для существующих сервисов из базового тоже копируются обновленные/нужные части.

A>А если кто переопределил через DI реализацию Interface1, но не переопределил Interface2 — то ошибка.
Какая ошибка? Во время работы? Во время исполнения?

A>Насколько это логично?
Ошибка — не логично. Раз вы предоставляете два интерфейса, значит, клиенты могут хотеть использовать их независимо. При этом клиент может вполне хотеть сконфигурировать свой Interface1 так, как ему нужно (а еще он может хотеть иметь несколько различных экземпляров Interface1 в разных конфигурациях, но это уже другая история). Здесь более важен вопрос, насколько важно иметь одинаковую конфигурацию (а еще лучше — ону и ту же реализацию), если клиент использует и Interface1, и Interface2. Например, почему просто не создавать приватный экземпляр Interface1 в фабричном методе для Interface2? В чем риски? Потребление ресурсов? Возможность расхождения конфигурации и поведения? Что-то еще? Ответы на эти вопросы позволят определить, как именно нужно интегрироваться с CI.

С учетом всего вышесказанного предлагаю план. Вы не делаете вообще никаких зависимостей на DI. Делаете несколько (статических) фабричных методов для создания Interface2. Предоставляете клиентам возможность конфигурировать все самим. Через 3-18 месяцев анализируете практику использования в реальных условиях и уже на ее основе решаете, что именно должно войти в ваш активатор с поддержкой DI. Потом регулярно (например, раз в год) смотрите, используется ли активатор или подходы конфигурации изменились. Это может потребовать нового активатора (если появился новый шаблон использования) или полного отказа от него (использование пошло расходящимися (diverging) путями).

Здравствуйте, andsm, Вы писали:

A>Разрабатывается библиотека, на C#
A>Библиотека предоставляет два публичных интерфейса, Interface1 и Interface2.
A>Классы, что реализуют Interface1 и Interface2, используют DI для получения ряда данных, таких, например, как конфигурация.
A>В классе, который реализует Interface2, нужно создать экземпляр класса, реализующего Interface1,
A>снаружи этот экземпляр и его методы не видны.

A>Я думаю — нужно ли в этом месте поддержать DI, чтобы создавать не класс, а то что зарегистрировано в DI?
A>Как-то мне кажется что DI внутри вообще не нужен. А если кто переопределил через DI реализацию Interface1, но не переопределил Interface2 — то ошибка.

A>Насколько это логично?
ничего непонятно. если есть интерфейсы то почему нельзя заменять реализации?
если 2 зависит так сильно от 1, то почему разделены?

Здравствуйте, andsm, Вы писали:

A>Разрабатывается библиотека, на C#

A>Насколько это логично

DI сам по себе не цель (разве что если у вас его использование в kpi не включили .Это инструмент, который позволяет снизить зависимость компонентов друг от друга и упростить написание unit-test. Просто посмотрите на свой код с этой стороны. Если у вас нет юнит тестирования, то зачем вам вообще DI? Если есть, то можете ли вы протестировать вашу логику изолированн, если не передаёте mock для Interface2 или нет? На основании этого и принимайте решение.

Здравствуйте, andsm, Вы писали:

Посмотрите, например, на библиотеку Mediatr. Она внутри себя использует DI (constructor injection), при этом в ядре библиотеки никаких ссылок на контейнеры нет. Задо есть еще несколько библиотек-адаптеров для популярных DI-фреймворков.