Должен ли Unity быть настроен в коде или файле конфигурации?

Рамка внедрения зависимостей Microsoft Unity может быть настроена либо через код, либо через файл конфигурации приложений (app.config).

Пример кода:

IUnityContainer container = new UnityContainer()
    .RegisterType<IInterface, ConcreteImplementation>();

Пример конфигурации:

<unity>
    <containers>
        <container>
            <types>
                <type type="IInterface, MyAssembly"
                      mapTo="ConcreteImplementation, MyAssembly" />

Каковы преимущества/недостатки каждого подхода? Я могу представить себе очевидное преимущество "Пользователи могут легко настроить ваше приложение", и очевидный недостаток "Пользователи могут легко разорвать ваше приложение", но есть ли что-то менее очевидное?

Ответ 1

Конфигурация XML действительно выгодна только для одной вещи: Поздняя привязка. С конфигурацией XML вы можете изменить, как ваше приложение составлено без перекомпиляции всего приложения. Это особенно актуально для приложений ISV, которые поддерживают определенную конфигурацию пользователя. ISV могут отправлять скомпилированное приложение по умолчанию, но позволяют пользователям/пользователям изменять части поведения, изменяя конфигурацию.

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

Конфигурация имеет тенденцию разбиваться при переименовании типов или сборок.
Вам нужно вручную скопировать соответствующие DLL файлы в выходной каталог (или создать конструкцию script).
Общая многословность затрудняет работу.
Поддержка инструмента слабее, чем для строго типизированного кода.

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

Ответ 2

Одним существенным недостатком конфигурации с помощью кода является то, что код требует ссылки на сборки. Это означает, что мне нужно добавить ссылки проекта или DLL в проект, чтобы код мог компилироваться.

Предполагается, что инъекция зависимости должна удалять зависимости между компонентами. Инициализация через код повторно вводит зависимость, требуя ссылки на проект или DLL. Файл конфигурации xml может ссылаться на любую сборку.

Если я создаю новую реализацию на основе интерфейса, я могу интегрировать новую реализацию в существующее приложение, добавив скомпилированную DLL и обновив файл конфигурации xml. Если я сделаю конфигурацию с помощью кода, мне нужно перекомпилировать приложение, чтобы заменить реализацию.

Ответ 3

Вопрос уже ответил, но я хочу обобщить мой опыт:

Используйте оба параметра. Я скрываю Code Configuration в Extension, когда у меня есть несколько стандартных конфигураций (обычно - это потому, что я использую IoC), тогда у меня есть несколько расширений, которые разделяют основную конфигурацию.

Я использую конфигурацию XML для нестандартных задач, таких как настройка производительности (в среде, где перекомпиляция занимает много времени).