Имеет ли смысл иметь XML файл конфигурации на модуль для DI?

Question

Я читал о DI и композиции root. Я читал в статье, что только приложение должно иметь композицию root, а не библиотеки.

Но давайте предположим, что у меня есть пакет многократного использования с некоторыми интерфейсами и их реализацией. Я хотел бы связать этот интерфейс с реализацией. Я думаю, что было бы обременительно, если бы пользователю пришлось делать все это самостоятельно.

Имеет ли смысл включать файл конфигурации XML DI в модуль многократного использования, который будет использоваться и обрабатываться в композиции root * * 1005

Answer 1

Хотя библиотеки классов не должны содержать корни композиции, вы всегда можете включить в свою библиотеку фабрику, которая создает график по умолчанию для простых случаев использования. Ваши типы в библиотеке по-прежнему будут опубликованы c, чтобы опытные пользователи могли составлять типы по-своему (например, украшать некоторые типы с помощью специального декоратора). Включенная вами фабрика также может быть параметризована для поддержки нескольких базовых c вариантов использования.

Что касается конфигурации XML, хотя она работает, поддерживать приложение, которое использует XML для конфигурации DI, в большинстве случаев очень сложно. случаи, когда после того, как тип был переименован в коде, имя типа в XML не будет автоматически переименовано.

Answer 2

Но давайте предположим, что у меня есть пакет многократного использования с некоторыми интерфейсами и их реализацией. Я хотел бы связать этот интерфейс с реализацией.

Почему ваш повторно используемый пакет предоставляет интерфейс и реализацию?

Вы можете предоставить конкретные классы, если Ваш повторно используемый пакет - библиотека . Как я пишу в DI-Friendly Framework :

Библиотека - это многократно используемый набор типов или функций, которые вы можете использовать в самых разных приложениях. Код приложения инициирует связь с библиотекой и вызывает ее.

В соответствии с принципом обращения зависимостей (DIP) клиент определяет абстрактный интерфейс своих зависимостей. Любой интерфейс, предоставленный библиотекой, будет нарушать DIP.

С другой стороны, ваш повторно используемый пакет может предоставить абстракцию (интерфейс или базовый класс), если вы ожидаете, что клиентский код предоставит реализацию. В этом случае пакет начинает больше походить на фреймворк, хотя там, вероятно, есть серая область. Обычно в таких случаях пакет не должен предоставлять какие-либо реализации интерфейса, или он может предоставлять некоторые для необязательного использования.

Возможно, существуют некоторые крайние случаи, когда оба интерфейса и (по умолчанию) реализация доставки с тем же пакетом может иметь смысл, но я не понимаю, как это оправдывает нечто большее, чем фабрика по умолчанию, которую рекомендует Якуб Массад. Вы можете сделать этот API Fluent Builder - это обычный шаблон для такого рода сценариев.

Вы можете предоставить все XML файлы конфигурации, которые вам понадобятся sh, если вы не хотите, чтобы кто-либо использовал ваши пакет.