Використання функції автопроксі

Досі ми розглядали явне створення проксі АОП за допомогою ProxyFactoryBean або аналогічного біна-фабрики.

Spring також дозволяє використовувати визначення бінів з "автопроксі", які можуть автоматично проксувати вибрані визначення бінів. Цей принцип побудований на інфраструктурі постпроцесора бінів Spring, яка дозволяє модифікувати будь-яке визначення біна в міру завантаження контейнера.

У цій моделі ти встановлюєш певні специфічні визначення бінів у XML-файлі визначення бина для конфігурування інфраструктури автопроксі. Це дозволяє оголошувати цілі, які підходять для автопроксіювання. Немає необхідності використовувати ProxyFactoryBean.

Зробити це можна двома способами:

• За допомогою автора автопроксі, який посилається на специфічні біни в поточному контексті.

• Особливий випадок створення автопроксі, який заслуговує на окремий розгляд: створення автопроксі на основі атрибутів метаданих на рівні джерела.

Визначення бінів з автопроксі

У цьому розділі розглядаються автори автопроксі, які надаються пакетом org.springframework.aop.framework.autoproxy.

BeanNameAutoProxyCreator

Клас BeanNameAutoProxyCreator — це BeanPostProcessor, який автоматично створює проксі АОП для бінів з іменами, що відповідають літерним значенням або знакам підстановки. У наступному прикладі показано, як створити бін BeanNameAutoProxyCreator:

<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="beanNames" value="jdk*,onlyJdk"/>
    <property name="interceptorNames">
        <list>
            <value>myInterceptor</value>
        </list>
    </property>
</bean>

Як і в ProxyFactoryBean, тут є властивість interceptorNames, а не список перехоплювачів для забезпечення коректної логіки роботи радників-прототипів. Іменовані "перехоплювачі" можуть бути радниками або порадами будь-якого типу.

Як і у випадку автопроксування в цілому, основний сенс використання BeanNameAutoProxyCreator полягає в послідовному застосуванні однієї і тієї ж конфігурації до кількох об'єктів при мінімальній конфігурації. Це найпопулярніший спосіб застосування декларативних транзакцій до кількох об'єктів.

Визначення бінів, імена яких збігаються, такі як jdkMyBean та onlyJdk у попередньому прикладі, є звичайними визначеннями бінів з цільовим класом. Проксі АОП автоматично створюється за допомогою BeanNameAutoProxyCreator. Цю ж пораду застосуємо до всіх відповідних бінів. Зверни увагу: якщо використовуються радники (а не перехоплювач у попередньому прикладі), зрізи можна по-різному застосовувати до різних бінів.

DefaultAdvisorAutoProxyCreator

Найбільш загальним, але надзвичайно ефективним творцем автопроксі є DefaultAdvisorAutoProxyCreator. Він автоматично застосовує відповідні радники у поточному контексті, без необхідності включати конкретні імена бінів до визначення біна радника з автопроксі. Він пропонує ті ж переваги послідовної конфігурації та уникнення дублювання, що і BeanNameAutoProxyCreator.

Використання цього механізму включає:

• Встановлення визначення біна DefaultAdvisorAutoProxyCreator.

• Встановлення будь-якої кількості радників в тому самому або суміжних контекстах. Зверни увагу, що це мають бути радники, а не перехоплювачі чи інші поради. Це необхідно, тому що має існувати обрізаний зріз, щоб перевіряти відповідність кожної ради визначенням бінів-кандидатів.

DefaultAdvisorAutoProxyCreator автоматично обчислює зріз, що міститься в кожному раднику, щоб дізнатися, яку пораду (якщо така є) він повинен застосувати до кожного бізнес-об'єкта (наприклад, businessObject1 та businessObject2 у прикладі).

Це означає, що будь-яка кількість радників може бути автоматично застосована до кожного бізнес-об'єкта. Якщо жоден з радників не збігатиметься з жодним методом бізнес-об'єкта, об'єкт не буде проксований. По мірі додавання бінів для нових бізнес-об'єктів, вони автоматично проксуються, якщо це необхідно.

Перевага автопроксування загалом полягає в тому, що воно не дозволяє коду, що робить виклики, або залежностям отримувати об'єкт, не забезпечений порадою. Виклик getBean("businessObject1") для цього ApplicationContext повертає проксі АОП, а не цільовий бізнес-об'єкт. (Підхід з "внутрішнім біном", показаний раніше, також надає цю перевагу).

У наступному прикладі створюється бін DefaultAdvisorAutoProxyCreator та інші елементи, розглянуті в цьому розділі:

<bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
<bean class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor">
    <property name="transactionInterceptor" ref="transactionInterceptor"/>
</bean>
<bean id="customAdvisor" class="com.mycompany.MyAdvisor"/>
<bean id="businessObject1" class="com.mycompany.BusinessObject1">
    <!-- Властивості опущені -->
</bean>
<bean id="businessObject2" class="com.mycompany.BusinessObject2"/>

DefaultAdvisorAutoProxyCreator дуже корисний, якщо тобі потрібно послідовно застосовувати ту саму пораду до багатьох бізнес-об'єктів. Після створення інфраструктури можна додавати нові бізнес-об'єкти без увімкнення специфічної конфігурації проксі. Ти також можеш додати інші аспекти (наприклад, аспекти трасування або моніторингу продуктивності) з мінімальними змінами в конфігурації.

DefaultAdvisorAutoProxyCreator пропонує підтримку фільтрації (за допомогою використання угоди про іменування, щоб обчислювалися лише певні радники, що дозволить використовувати безліч по-різному налаштованих AdvisorAutoProxyCreator в одній фабриці) та впорядкування. Радники можуть реалізовувати інтерфейс org.springframework.core.Ordered для забезпечення належного впорядкування, якщо це проблема. TransactionAttributeSourceAdvisor, який використовується в попередньому прикладі, має значення впорядкованості, яке налаштовується. За замовчуванням використовується значення "неупорядкований".