Что случилось с реализацией конфигурации Внедрения зависимости в коде?

Мартин Фаулер довольно хорошо осветил это решение здесь:

http://martinfowler.com/articles/injection.html

Избегая стремления к плагиату ... просто прочтите раздел «Код или файлы конфигурации».

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

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

Главное, что, на мой взгляд, достигается с помощью конфигурации XML. заставляет разработчиков думать о внедрении зависимостей и разделении задач. в Spring (среди прочего) он также предоставляет удобный крючок для зависания ваших прокси AOP и тому подобного. И то, и другое может быть достигнуто в конфигурации Java, просто менее очевидно, где нарисованы линии, и может возникнуть тенденция к повторному введению прямых зависимостей и спагетти-кода.

Для информации, существует Spring project чтобы позволить вам выполнять настройку в коде.

Проект Spring Java Configuration (сокращенно JavaConfig) предоставляет типобезопасный, чистый вариант Java для настройки контейнера Spring IoC. Хотя XML является широко используемым подходом к конфигурации, гибкость Spring и внутренняя обработка определений компонентов на основе метаданных означает, что альтернативы конфигурации XML легко реализовать.

XML не предназначен для того, чтобы иметь логику, и это далеко не язык программирования.

XML используется для хранения ДАННЫХ таким образом, чтобы их было легко понять и изменить.

У вас есть скажем, он часто используется для хранения определений, а не бизнес-логики.

Вы упомянули Spring в комментарии к своему вопросу, поэтому это говорит о том, что вас может заинтересовать тот факт, что Spring 3 позволяет вам выражать контексты вашего приложения на Java, а не в XML .

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

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

Это плохо, потому что это усложняет тестирование.

Если вы пишете код и используете такие методы, как getApplicationContext () для получения зависимостей, вы выбрасываете некоторые ] преимуществ внедрения зависимостей.

Когда вашим объектам и службам не нужно знать, как создавать или приобретать ресурсы, от которых они зависят, они более слабо связаны с этими зависимостями.

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

Кроме того, если вы можете сопротивляться побуждению использовать getApplicationContext () и другие методы DI на основе кода, тогда вы можете (иногда) полагаться на пружинное автоматическое подключение, что означает еще меньше работы по настройке. Работа с конфигурацией, будь то код или XML, утомительна, верно?

По моему опыту, тесное общение между командой разработчиков и командой инфраструктуры может быть усилено частыми выпусками. Чем больше вы выпускаете, тем больше вы действительно знаете, каковы различия между вашими средами. Это также позволяет вам удалить ненужную настраиваемость.

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

Когда у меня есть команда, развертывающая внутреннюю приложений, я стараюсь использовать конфигурацию в коде для всех архитектурных проблем (пулы соединений и т. д.) и конфигурацию в файлах для всех конфигураций среды (имена пользователей, строки подключения, IP-адреса). Если в разных средах существуют разные архитектурные проблемы, я объединю их в один класс, container.config = ProductionSizedConfiguration

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

Однако это не всегда подходит. Есть несколько вещей, которые повлияют на ваш выбор:

1) сколько времени пройдет после выпуска новой капли, прежде чем она будет успешно развернута в каждой производственной среде и вы получите отзыв об этой среде (время цикла) 2) Изменчивость в развернутых средах 3) Точность обратной связи, полученной от производственных сред.

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

Но рубрика такова: настраиваемость заменяет общение.