Какой предпочтительный способ связывания зависимостей с использованием контейнера IoC?

Question

Я считаю, что большинство контейнеров IoC позволяют связывать зависимости с файлом конфигурации XML. Каковы плюсы и минусы использования файла конфигурации и регистрации зависимостей в коде?

Answer 1

Эти плюсы и минусы основаны на моей работе с весной. Может быть немного другой для других контейнеров.

XML

про

• гибкий
• более мощный, чем аннотации в некоторых областях
• очень явное моделирование зависимостей ваших классов

против

• многословным
• трудности с рефакторингом
• переключение между несколькими файлами

Аннотации

про

• меньше переключений файлов
• автоматическая настройка для простых соединений
• менее многословно, чем xml

против

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

код

про

• Может использовать языки со строгой типизацией (например, C #, Java)
• Некоторая проверка во время компиляции (хотя не может статически проверять зависимости)
• Может использовать преимущества DSL (например, Binsor, Fluent интерфейсы)
• Менее многословно, чем XML (например, вам не нужно всегда указывать полное имя сборки (при разговоре .net))

против

• подключение по коду может привести к сложному подключению
• жесткие зависимости от контейнера IOC в кодовой базе

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

[РЕДАКТИРОВАТЬ: Я заимствовал код Mauschs PRO]

Answer 2

XML плюсы:

• Может изменять проводку и параметры без перекомпиляции. Иногда это удобно иметь при переключении сред (например, вы можете переключить поддельного отправителя электронной почты, используемого в dev, на реального отправителя электронной почты в производстве)

Код плюсов:

• Может использовать языки со строгой типизацией (например, C #, Java)
• Некоторая проверка во время компиляции (хотя не может статически проверять зависимости)
• Рефакторинг с использованием обычных инструментов рефакторинга.
• Может использовать преимущества DSL (например, Binsor, Fluent интерфейсы)
• Менее многословно, чем XML (например, вам не нужно всегда указывать полное имя сборки (при разговоре .net))

Answer 3

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

Answer 4

Я предполагаю, что под "регистрацией зависимостей в коде" вы подразумеваете "использовать новые".

'new' - это чрезвычайно мощная структура внедрения зависимостей. Это позволяет вам «вводить» ваши «зависимости» во время создания объекта, то есть не иметь забытых параметров или наполовину построенных объектов.

Другое важное потенциальное преимущество заключается в том, что когда вы используете инструменты рефакторинга (скажем, в Resharper или IntelliJ), также призывает к новым изменениям

В противном случае вы можете использовать какую-то бессмыслицу XML и рефакторинг с XSL.