目前为止,关于autowire的描述都只是针对单独的实例,其实也支持集合。在任何需要得到所有context中某种特定类型的Spring管理对象的时候,只需要简单地在一个强类型(strongly-typed)集合上加注@Autowired 注解。
|
本章节最后一个值得指出的特性是自动装配的使用替代了Spring的Aware接口。在Spring2.5之前,如果某个对象需要一个Spring context的ResourceLoader的引用,它可以通过实现ResourceLoaderAware的方式使得Spring通过setResourceLoader(ResourceLoader resourceLoader)方法来提供该依赖。借助同样的方法可以得到Spring管理的MessageSource的引用,甚至可以得到ApplicationContext本身。对于Spring2.5用户而言,这个行为现在通过autowiring得到全面支持(需要指出的是包含这些Spring特定依赖的时候应该考虑周到,特别是它们只能用于从业务逻辑清楚地分割出来的基础构架代码中)。
|
自动侦测Spring组件
从2.0版本开始,Spring引入了构造型(stereotype)注解的概念以及将@Repository注解作为数据访问代码的标记的方法。在此基础上,Spring2.5又加入了两个新的注解 —— @Service和@Controller 来完成为通常的三层架构(数据访问对象、服务、web控制器)角色委任。Spring2.5也引入了泛型@Component注解,其他构造型可从逻辑上对其进行扩展。通过清晰地指明应用程序的角色,这些构造型方便了Spring AOP和post-processor的使用,这些post-processor给基于这些角色的加了注解的对象提供了附加行为。比如,Spring2.0引入了PersistenceExceptionTranslationPostProcessor对任何带有@Repository 注解的对象自动激活其数据访问异常转换。
这些注解同样可以结合Spring2.5其他一些新性能来使用:自动侦测classpath上的组件。尽管XML已经成为最常见的Spring元数据的格式,但它决不是唯一选择。实际上,Spring容器内的元数据是由纯Java来表示的,当XML被用来定义Spring管理对象时,在实例化过程之前,那些定义会被解析并转化成Java对象。Spring2.5的一个巨大的新功能是支持从源码层注解读取元数据。因而,上文描述的自动装配机制使用注解的元数据来注入依赖,但它仍然需要注册至少一个bean定义以便提供每个Spring管理对象的实现类。组件扫描功能则使得这个XML中最起码的bean定义都不再存在需求性。
正如上面所示,Spring注解驱动的自动装配可以在不牺牲细粒度控制的前提下极大程度地减少XML的使用。组件侦测机制将这个优点更发扬光大。全面替代XML中的配置不再必要,组件扫描反而可以处理XML元数据来简化整体配置。结合XML和注解驱动技术可以得到一个平衡优化的方法,这在2.5版本的PetClinic范例中有详细阐述。在该范例中,基础构架组件(数据源、事务管理等)结合上文提到的外化属性在XML中定义。数据访问层对象也有部分在XML中定义,它们的配置也都利用了@Autowired注解来简化依赖注入。最后,web层控制器完全不在XML中显式定义,相反,下面提供的这段配置被用来触发所有Web控制器的自动侦测:
|
需要注意到的是这段示例中使用到了base-package属性。组件扫描的默认匹配规则会递归侦测该包(多个包可以以逗号分隔的list方式提供)内的所有类的所有Spring构造型注解。正因为如此,PetClinic应用程序范例中的各类控制器的实现都采用了@Controller注解(Spring的内置构造型之一)。请看下面这个例子:
|
自动侦测组件在Spring容器中注册,就像它们在XML中被定义一样。如上所示,那些对象可以轮流利用注解驱动的自动装配。
组件扫描的匹配规则可以通过过滤器(filter)来自定义,以根据类型、AspectJ表达式、或针对命名模式的正则表达式来决定包含或不包含哪些组件。默认的构造型也可以被禁用。比如这里有一个配置的例子,这个配置会忽略默认的构造型,但会自动侦测名字以Stub打头或者包含@Mock注解的所有类:
类型匹配的限制性也可以用排他的过滤器控制。例如,除了@Repository注解外其他都依赖于默认过滤器,那么就需要加入一个排他过滤器(exclude-filter)。
很明显,有很多方法可以扩展组件扫描来注册自定义的类型。构造型注解是最简单的选择,所以构造型概念本身也是可扩展的。像先前提到的,@Component是泛型模型,@Repository、@Service,和@Controller注解都从该构造型逻辑扩展而得。正因为如此,@Component可被用来作为元注解(也就是说,在另外的注解上声明的注解),所有具有@Component元注解的自定义注解都会被默认扫描匹配规则自动侦测到。一个例子就有希望让你领会到其实它根本没有听起来那么难。
让我们回想一下在讲@PostConstruct和@PreDestroy生命周期注解的时候的假想的后台任务。也许一个应用程序有很多很多这样的后台任务,这些任务实例需要XML bean定义以便在Spring context里注册并使它们自己的生命周期方法在正确时候被调用。利用组件扫描就不再需要这些显式的XML bean定义。如果这些后台任务都实现一个相同的接口或者都沿用同样的命名惯例,那么可以用include-filters。然而,更简单的方法是为这些任务对象创建一个注解并提供@Component元注解。
|
相关专题
- 电脑配置手册 (8385篇文章)
- 服务器配置专栏 (10960篇文章)
- Spring开源框架技术 (672篇文章)
- Spring开发技术篇 (295篇文章)
- J2SE综合:浅谈java程序发布之 jre 篇 (11次浏览)
- JAVA代码中使用魔法数值 (8次浏览)
- Hibernate缓存管理 (6次浏览)
- JAVA代码应该流畅和结构化 (5次浏览)
- Java JVM设置对性能的影响 (4次浏览)
- 开发框架:深入了解 Struts Validator (3次浏览)
- Java中的通信机制及与C/C API的集成 (1次浏览)
- 用Hibernate实现领域对象的自定义字段 (1次浏览)
- Java语言入门 简述Java语言回收机制 (0次浏览)
- 2008年Java开发者最迫切的五个期望 (0次浏览)



