Struts调用Spring服务类的三种方法 博客分类: 99_杂项 SpringStrutsIOC配置管理项目管理
程序员文章站
2024-02-05 17:58:40
...
用SSH做了几个项目,现在总结一下Struts Action中调用Spring Service的方法,大家有好的实现,请继续补充:
1.老爸操持型
这种类型,即是在BaseAction中提供一个getBean(String beanName)的父类方法,业务Action 在需要Serivce时,调用父类的getBean()得到Object型的Service,再Cast。
e.g.
2.自已动手型
自己动手 丰衣足食,再加了自从有了IoC,所谓动手也只是衣来后的伸手和饭来后的张口。自己动手型,即是利用Spring的IoC,将IoC容器中的Service注入到Action中,当然Action需要提供注入服务有setter.
如果采用这种方式,首先需要让Spring接管Struts,然后在Spring配置文件中,配置Action的注入属性。
首先.在struts-config.xml将Spring引狼入室。
然后,Struts再向Spring投怀送抱:
聪明的你一下就看出“/userAction ”即是com.stamen.web.UserAction在Struts中的配置名。
3.朋友帮忙型 朋友多了好办事,凡事都自己动手总有一天会活活累死,所有Action为自己需要的Service提供setter,并且在Spring中注入,好累啊。小学生都在减负了,我们也来为Action减减负吧--提供一个专门
查找Serivice的ServiceLocator,负责获取所有的Service,该类为每个Service提供专门的获得方法,如:
Action要用哪个Serivce时,直接通过ServiceLocator.getXxxService()就可以获得了,省去了
“老爸操持型”指定Service 名和Cast的繁琐,比在Spring中IoC来IoC去也来得省心省力。
下面做一个自己的分析小结:
1.“老爸操持型” 将serviceName分散到代码中,到时配置文件中serviceName一改,得牵一毛而动全身->维护性差;且要进行Cast转换,怎一个繁字了得。
2.“自己动手型”也不好,不但在Action中要添加get/setXxxService代码,而且还要在Struts和Spring的配置文件中做好群众的大串连工作,难道我们的配置还不够多吗?吃回香豆的,你别又跳出来啊:)
3.“朋友帮忙型”,目前,我认为是比较好的方式,ServiceLocator象一个服务周到,工作到位的房产“中介”,我们要租房子 何必满街跑啊?TMD 这个月我又交了3K房租,也不知道李大伦,李金宝之流规矩后,房价能不能降些,我想有个蜗牛的家 已经唱了好几年了--跑题了,睡觉去了:)
1.老爸操持型
这种类型,即是在BaseAction中提供一个getBean(String beanName)的父类方法,业务Action 在需要Serivce时,调用父类的getBean()得到Object型的Service,再Cast。
e.g.
public class BaseAction extends DispatchAction { ... public Object getBean(String name) { if (ctx == null) { ctx = WebApplicationContextUtils .getRequiredWebApplicationContext(servlet.getServletContext()); } return ctx.getBean(name); } }
2.自已动手型
自己动手 丰衣足食,再加了自从有了IoC,所谓动手也只是衣来后的伸手和饭来后的张口。自己动手型,即是利用Spring的IoC,将IoC容器中的Service注入到Action中,当然Action需要提供注入服务有setter.
如果采用这种方式,首先需要让Spring接管Struts,然后在Spring配置文件中,配置Action的注入属性。
首先.在struts-config.xml将Spring引狼入室。
<plug-in className="org.springframework.web.struts.ContextLoaderPlugIn"> <set-property property="contextConfigLocation" value="/WEB-INF/action-servlet.xml" /> </plug-in>
然后,Struts再向Spring投怀送抱:
<bean id="userService" class="com.nic.service.UserServiceImpl"> <property name="userDao"> <ref bean="userDao" /> </property> </bean> <bean name="/userAction" class="com.stamen.web.UserAction"> <property name="userService" ref="userService"/> </bean>
聪明的你一下就看出“/userAction ”即是com.stamen.web.UserAction在Struts中的配置名。
3.朋友帮忙型 朋友多了好办事,凡事都自己动手总有一天会活活累死,所有Action为自己需要的Service提供setter,并且在Spring中注入,好累啊。小学生都在减负了,我们也来为Action减减负吧--提供一个专门
查找Serivice的ServiceLocator,负责获取所有的Service,该类为每个Service提供专门的获得方法,如:
public class ServiceLocator { private static ApplicationContext factory = null; public static void init(ApplicationContext ctx) { factory = ctx; } public static LogService getLogService() { return (LogService) ServiceLocator.getBean("logService"); } public static UserService getUserService() { return (UserService) ServiceLocator.getBean("userService"); } public static PieeService getPieeService() { return (PieeService) ServiceLocator.getBean("pieeService"); } public static PieeGrid getPieeListService() { return (PieeGrid) ServiceLocator.getBean("pieeListService"); } ... }
Action要用哪个Serivce时,直接通过ServiceLocator.getXxxService()就可以获得了,省去了
“老爸操持型”指定Service 名和Cast的繁琐,比在Spring中IoC来IoC去也来得省心省力。
下面做一个自己的分析小结:
1.“老爸操持型” 将serviceName分散到代码中,到时配置文件中serviceName一改,得牵一毛而动全身->维护性差;且要进行Cast转换,怎一个繁字了得。
2.“自己动手型”也不好,不但在Action中要添加get/setXxxService代码,而且还要在Struts和Spring的配置文件中做好群众的大串连工作,难道我们的配置还不够多吗?吃回香豆的,你别又跳出来啊:)
3.“朋友帮忙型”,目前,我认为是比较好的方式,ServiceLocator象一个服务周到,工作到位的房产“中介”,我们要租房子 何必满街跑啊?TMD 这个月我又交了3K房租,也不知道李大伦,李金宝之流规矩后,房价能不能降些,我想有个蜗牛的家 已经唱了好几年了--跑题了,睡觉去了:)