精简的代理定义 (Concise Proxy Definitions)

特别是在定义事务代理时，你可能会产生许多相似的代理定义。使用父子 Bean 定义以及内部 Bean 定义，可以使代理定义更加整洁和精简。

首先，我们为代理创建一个父级（模板）Bean 定义，如下所示：

<bean id="txProxyTemplate" abstract="true"
		class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
	<property name="transactionManager" ref="transactionManager"/>
	<property name="transactionAttributes">
		<props>
			<prop key="*">PROPAGATION_REQUIRED</prop>
		</props>
	</property>
</bean>

这个 Bean 本身永远不会被实例化，因此它实际上可以是“不完整”的定义。然后，每个需要创建的代理都是一个子 Bean 定义，它将代理的目标对象包装为内部 Bean 定义（因为目标对象本身通常不会被直接使用）。以下示例显示了这样一个子 Bean：

<bean id="myService" parent="txProxyTemplate">
	<property name="target">
		<bean class="org.springframework.samples.MyServiceImpl">
		</bean>
	</property>
</bean>

你可以覆盖父模板中的属性。在以下示例中，我们覆盖了事务传播设置：

<bean id="mySpecialService" parent="parent="txProxyTemplate">
	<property name="target">
		<bean class="org.springframework.samples.MySpecialServiceImpl">
		</bean>
	</property>
	<property name="transactionAttributes">
		<props>
			<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
			<prop key="store*">PROPAGATION_REQUIRED</prop>
		</props>
	</property>
</bean>

请注意，在父 Bean 示例中，我们通过将 abstract 属性设置为 true，明确地将父 Bean 定义标记为抽象的。默认情况下，ApplicationContext（但简单的 BeanFactory 不会）会预实例化所有单例。因此，如果你有一个（父）Bean 定义仅打算用作模板，并且该定义指定了一个类，请务必确保将 abstract 属性设置为 true。否则，应用程序上下文实际上会尝试预实例化它。

---

补充教学

1. 配置重用：配置领域的“模板方法模式”

在大量的 XML 配置时代，父子 Bean 定义（parent 属性）是处理“配置爆炸”的利器。

• DRY 原则：将共同的 transactionManager、interceptorNames 或代理配置提取到父 Bean 中。
• 局部覆盖：子 Bean 只需关注自己的 target 以及需要特殊处理的属性（如特定的事务规则）。

2. 深入理解 abstract="true"

• 为什么要设为抽象？
  • 如果父 Bean 配置了 class 属性（如 TransactionProxyFactoryBean），Spring 会尝试用反射创建它。
  • 但作为一个模板，它往往缺少关键属性（比如没有 target），直接初始化会导致 Bean 创建失败抛出异常。
  • abstract="true" 告诉容器：“这只是个图纸，别把它盖成房子”。
• 容器差异：ApplicationContext 在启动时就会扫描并创建所有单例 Bean 以便尽早暴露配置错误。这就是为什么在 ApplicationContext 中 abstract 属性尤为重要的原因。

3. 现代替代方案：注解与元注解

如果你正在使用 Java 配置（Spring Boot），这种“精简”配置的需求通常通过以下方式解决：

• @Transactional 继承：在接口或类级别标注通用事务规则，在具体方法上覆盖。
• 自定义复合注解：通过自定义注解（Meta-annotation）组合多个 AOP 和配置注解。

提示

虽然本章内容侧重于传统的 XML 配置，但其背后的“基类配置 + 差异化覆盖”的思想在任何时代的软件工程中都是通行的。