为了与它提供的其他重要概念的抽象相一致Spring提供了一个对元数据实现的外观（facade） 以orgtadataAttributes这个接口的形式来表示
这样一个外观很有价值因为下面几个原因
目前还没有一个标准的元数据解决方案 Java 版本会提供一个但是在Spring版本的时候 Java 仍是beta版本而且至少两年内还是需要对和版本的应用程序提供元数据支持 现在Spring打算提供一些可以工作的解决方案 在一个重要的环境下等待并不是个好的选择
目前的元数据API例如Commons Attributes（被Spring 使用） 测试起来很困难Spring提供了一个简单的更容易模拟的元数据接口
即使当Java 在语言级别提供了对元数据的支持时提供了一个如此的抽象仍然是有价值的:
JSR的元数据是静态的它是在编译时与某一个类关联而在部署环境下是不可改变的 这里会需要多层次的元数据以支持在部署时重载某些attribute的值－－举例来说 在一个XML文件中定义用于覆盖的attribute
JSR的元数据是通过Java反射API返回的这使得在测试时无法模拟元数据Spring提供了一个简单的接口来允许这种模拟
虽然Spring在Java 达到它的GA版本之前将支持JSR但仍会继续提供一个attribute抽象API
Spring的Attributes接口看起来是这样的
public interface Attributes {
Collection getAttributes(Class targetClass);
Collection getAttributes(Class targetClass Class filter);
Collection getAttributes(Method targetMethod);
Collection getAttributes(Method targetMethod Class filter);
Collection getAttributes(Field targetField);
Collection getAttributes(Field targetField Class filter);
}
这是个最普通不过的命名者接口JSR能提供更多的功能比如定义在方法参数上的attributes 在版本时Spring目的在于提供元数据的一个子集使得能象EJB或NET一样提供有效的声明式企业级服务版本以后Spring将提供更多的元数据方法
注意到该接口像NET一样提供了Object类型的attibute 这使得它区别于一些仅提供String类的attribute的attribute系统 比如Nanning Aspects和JBoss （在DR版本时）支持Object类型的attribute有一个显着的优点它使attribute含有类层次还可以使attribute能够灵活的根据它们的配置参数起作用
对于大多数attribute提供者来说attribute类的配置是通过构造函数参数或JavaBean的属性完成的Commons Attributes同时支持这两种方式
同所有的Spring抽象API一样Attributes是一个接口这使得在单元测试中模拟attribute的实现变得容易起来
