(2)类UpperAction实现Action接口,在此类中,定义一个String型的域message,并提供相应的setter和getter方法,实现的execute方法如下:
publicStringexecute(Stringstr){
return(getMessage()+str).toUpperCase();
}
(3)编写Spring配置文件(bean.
xml)
<beans>
<beanid="TheAction"class="net.chen.spring.qs.UpperAction">
<propertyname="message">
<value>HeLLo</value>
</property>
</bean>
</beans>
(4)测试代码
publicvoidtestQuickStart(){
ApplicationContextctx=new
FileSystemXmlApplicationContext("bean.xml");
Actiona=(Action)ctx.getBean("TheAction");
System.out.println(a.execute("RodJohnson"));
}
上面的测试代码中,我们根据"bean.xml"创建了一个ApplicationContext实例,并从此实例中获取我们所需的Action实现,运行测试代码,我们看到控制台输出:
……
HELLORODJOHNSON
仔细观察一下上面的代码,可以看到:
(1)我们的组件并不需要实现框架指定的接口,因此可以轻松的将组件从Spring中脱离,甚至不需要任何修改,这在基于EJB框架实现的应用中是难以想象的。
(2)组件间的依赖关系减少,极大改善了代码的可重用性。Spring的依赖注入机制,可以在运行期为组件配置所需资源,而无需在编写组件代码时就加以指定,从而在相当程度上降低了组件之间的耦合。
Spring给我们带来了如此这般的好处,那么,反过来,让我们试想一下,如果不使用Spring框架,回到我们传统的编码模式,情况会是怎样呢?
首先,我们必须编写一个配置文件读取类,以实现Message属性的可配置化。
其次,得有一个Factory模式的实现,并结合配置文件的读写完成Action的动态加载。于是,我们实现了一个ActionFactory来实现这个功能:
publicclassActionFactory{
publicstaticActiongetAction(StringactionName){Propertiespro=newProperties();
try{
pro.load(newFileInputStream("config.properties"));
StringactionImplName=(String)pro.get(actionName);
StringactionMessage=(String)pro.get(actionName+"_msg");
Objectobj=Class.forName(actionImplName).newInstance();
BeanUtils.setProperty(obj,"message",actionMessage);
return(Action)obj;
}catch(FileNotFoundExceptione){
……
}
}
配置文件则采用properties文件形式如下所示:
TheAction=net.chen.spring.qs.UpperAction
TheAction_msg=HeLLo
测试代码也作相应修改。现在不论实现的好坏,总之通过上面新增的多行代码,终于实现了类似的功能。如果现在有了一个新的需求,这样这个ActionFactory每次都新建一个类的实例,显然这对系统性能不利,考虑到我们的两个Action都是线程安全的,修改一下ActionFactory,保持系统中只有一个Action实例供其它线程调用。另外Action对象创建后,需要做一些初始化
工作。修改一下ActionFactory,使其在创建Action实例之后,随即就调用Action.init方法执行初始化。Action的处理这样就差不多了。下面我们来看看另外一个Factory