Подробно о зависимостях и конфигурациях
Как уже упоминалось в предыдущем разделе, вы можете определить свойства бина и аргументы конструктора как ссылки на другие управляемые бины (взаимодействующие объекты) или как встроенные значения. Конфигурационные метаданные Spring на основе XML поддерживают для этой задачи типы подэлементов в элементах и .
Прямые значения (примитивы (primitives), строки (stringes) и т.д.)
Атрибут value элемента определяет свойство или аргумент конструктора в виде удобного для восприятия человеком строкового представления. Служба преобразования Spring используется для преобразования этих значений из String в реальный тип свойства или аргумента. В следующем примере показаны различные задаваемые значения:
В следующем примере используется пространство имен p-namespace для еще более лаконичной конфигурации XML:
Предыдущий XML более лаконичен. Однако ошибки обнаруживаются во время выполнения, а не во время проектирования, если только вы не используете интегрированную среду разработки (IDE) (например, IntelliJ IDEA или Spring Tools для Eclipse), которая поддерживает автоматическое заполнение свойств при создании определений бинов. Настоятельно рекомендуется пользоваться таким вспомогательным функционалом IDE.
Вы также можете настроить экземпляр java.util.Properties следующим образом:
jdbc.driver.className=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/mydb Контейнер Spring преобразует текст внутри элемента в экземпляр java.util.Properties с помощью механизма PropertyEditor JavaBeans. Это хорошее сокращение, и это один из немногих случаев, в которых команда Spring отдает предпочтение использованию вложенного элемента , а не стилю атрибута value .
Элемент idref
Элемент idref — это просто безошибочный способ передать id (строковое значение — не ссылку) другого бина в контейнере в элемент или . В следующем примере показано, как его использовать:
Предыдущий фрагмент кода определения бина в точности эквивалентен (во время выполнения) следующему фрагменту:
Первая форма предпочтительнее второй, поскольку использование тега idref позволяет контейнеру проверять во время развертывания, что именованный бин, на который дается ссылка, действительно существует. Во втором варианте проверка значения, передаваемого в свойство targetName бина client , не производится. Ошибки обнаруживаются (скорее всего, с критическими последствиями) только во время создания экземпляра client бина. Если client бин является prototype бином, эта ошибка и возникающее исключение можно обнаружить только спустя долгое время после развертывания контейнера.
Атрибут local в элементе idref больше не поддерживается в XSD бинов версии 4.0, поскольку он больше не предоставляет значения по сравнению с обычной ссылкой на bean . При переходе на схему 4.0 измените существующие ссылки idref local на idref bean .
Распространенное место (по крайней мере, в версиях, предшествующих Spring 2.0), где элемент возвращает значение, является конфигурация АОП-перехватчиков (interceptors) в определении бина ProxyFactoryBean . Использование элементов при указании имен перехватчиков предотвращает неправильное написание идентификатора перехватчика.
Ссылки на другие бины (взаимодействующие объекты)
Элемент ref является конечным элементом внутри элемента определения или . Здесь вы задаёте значение указанного свойства бина как ссылку на другой бин (взаимодействующий объект), управляемый контейнером. Бин, на который дается ссылка, является зависимостью бина, свойство которого нужно задать, и он инициализируется по требованию, по мере необходимости, до того, как свойство будет задано. (Если взаимодействующий объект является бином-одиночкой, он может быть уже инициализирован контейнером). Все ссылки в конечном итоге являются ссылками на другой объект. Определение области видимости и валидация зависят от того, задаете вы ID или имя другого объекта через атрибут bean или parent .
Указание целевого бина через атрибут bean тега является наиболее общей формой и позволяет создать ссылку на любой бин в том же контейнере или родительском контейнере, независимо от того, находится ли он в том же XML-файле. Значение атрибута bean может совпадать с атрибутом id целевого бина или быть таким же, как одно из значений в атрибуте name целевого бина. В следующем примере показано, как использовать элемент ref :
Задание целевого бина через атрибут parent создает ссылку на бин, который находится в родительском контейнере текущего контейнера. Значение атрибута parent может совпадать либо с атрибутом id целевого бина, либо с одним из значений в атрибуте name целевого бина. Целевой бин должен находиться в родительском контейнере текущего. Следует использовать этот вариант ссылки на бин в основном тогда, когда имеется иерархия контейнеров и вы хотите обернуть существующий бин в родительском контейнере прокси, который имеет то же имя, что и родительский бин. Следующая пара листингов показывает, как использовать атрибут parent :
Атрибут local в элементе ref больше не поддерживается в XSD бинов версии 4.0, поскольку он больше не предоставляет значения по сравнению с обычной ссылкой на bean . При переходе на схему 4.0 измените существующие ссылки ref local на ref bean .
Внутренние бины
Элемент внутри элементов или содержит определение внутреннего бина, как показано в следующем примере:
Определение внутреннего бина не требует определенного ID или имени. Если задано, контейнер не будет использовать такое значение в качестве идентификатора. Контейнер также игнорирует флаг scope при создании, поскольку внутренние бины всегда анонимны и всегда создаются вместе с внешним бином. Невозможно получить доступ к внутренним бинам независимо или внедрить их во взаимодействующие бины, кроме как в объемлющий бин.
В крайнем случае, можно получить обратные вызовы уничтожения из специальной области видимости — например, для внутреннего бина, входящего в область видимости request, содержащегося внутри бина-одиночки. Создание экземпляра внутреннего бина привязано к содержащему его бину, но обратные вызовы уничтожения позволяют ему участвовать в жизненном цикле области видимости запроса. Это не совсем привычний сценарий. Внутренние бины обычно просто совместно используют область видимости содержащего их бина.
Коллекции
Элементы , , , и задают свойства и аргументы типов Collection List , Set , Map и Properties на основе Java, соответственно. В следующем примере показано, как их использовать:
administrator@example.org support@example.org development@example.org a list element followed by a reference
just some string Значением ключа или значением в ассоциативных массивах, или задающей величиной также может выступать один из следующих элементов:
bean | ref | idref | list | set | map | props | value | nullОбъединение коллекций
Контейнер Spring также поддерживает объединение коллекций. Разработчик приложения может определить родительский элемент , , или и сделать так, чтобы дочерние элементы , , или наследовали и переопределяли значения из родительской коллекции. То есть значения дочерней коллекции являются результатом объединения элементов родительской и дочерней коллекций, при этом элементы дочерней коллекции переопределяют значения, указанные в родительской коллекции.
В этом разделе, посвященном объединению, рассмотрен механизм бинов «родитель-потомок». Читатели, не знакомые с определениями родительских (parent) и дочерних (child) бинов, возможно, захотят ознакомиться с соответствующим разделом, прежде чем продолжить.
В следующем примере показано объединение коллекций:
administrator@example.com support@example.com sales@example.com support@example.co.uk
Обратите внимание на использование атрибута merge=true в элементе свойства adminEmails определения child бина. Если child бин разрешается и создается контейнером, то полученный экземпляр имеет коллекцию adminEmails Properties , которая содержит результат объединения коллекции adminEmails дочернего бина с коллекцией adminEmails родительского бина. В следующем листинге показан результат:
administrator=administrator@example.com sales=sales@example.com support=support@example.co.uk
Набор значений дочерней коллекции Properties наследует все элементы свойств от родительской , а значение дочерней коллекции для значения support переопределяет значение в родительской коллекции.
Такое поведение объединения применяется аналогично типам коллекций , и . В конкретном варианте элемента сохраняется семантика, связанная с типом коллекции List (то есть понятие ordered коллекции значений). Значения родительского списка предшествуют всем значениям дочернего списка. В случае типов коллекций Map , Set и Properties упорядочивание отсутствует. Следовательно, семантика упорядочивания не действует для типов коллекций, лежащих в основе связанных с ними типов реализации Map , Set и Properties , которые контейнер использует внутри.
Ограничения при объединении коллекций
Нельзя объединять коллекции разных типов (например, Map и List ). Если попытаться это сделать, будет сгенерировано соответствующее Exception . Атрибут merge должен быть указан в нижнем, наследуемом, дочернем определении. Указание атрибута merge в определении родительской коллекции является избыточным и не приводит к желаемому объединению.
Строго типизированная коллекция
Благодаря поддержке в Java обобщенных типов, можно использовать строго типизированные коллекции. То есть можно объявить тип Collection таким образом, что он может содержать только (например) элементы String . Если вы используете Spring для внедрения строго типизированной Collection с зависимостями в бин, то можно воспользоваться поддержкой Spring по преобразованию типов, чтобы элементы экземпляров строго типизированной Collection были преобразованы в соответствующий типу перед добавлением в Collection . Нижеследующе определение класса Java и бина демонстрируют, как это сделать
public class SomeClass < private Mapaccounts; public void setAccounts(Map accounts) < this.accounts = accounts; >>