精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2004-10-29
偶是这样做的:
权限判断提供一个service, 这个service定义在spring里面: public interface SecurityService { public boolean hasPermission(UserLogin userLogin, String permission);; } WebWork的action如果需要进行权限判断, 那么implements一个mark接口(Protected), 实现hasPermission方法: public class BaseAction extends ActionSupport implements Protected { public boolean hasPermission(); { return true; } } 用到SecurityService的action, 则采用ext-ref注入: public class BaseAdminAction extends BaseAction { public boolean hasPermission(); { return securityService.hasPermission(userLogin, "ADMIN");; } } |
|
返回顶楼 | |
发表时间:2004-10-29
总之你用external-ref实现注入了。也就是说你自己用external-ref实现了本来可以用spring管理的一些事情。
那如果有跨action chain的transaction呢? |
|
返回顶楼 | |
发表时间:2004-10-29
曹晓钢 写道 总之你用external-ref实现注入了。也就是说你自己用external-ref实现了本来可以用spring管理的一些事情。
那如果有跨action chain的transaction呢? 没错, but, 偶不喜欢spring aop的设计, xwork的interceptor对于web应用的action而言, 足够简洁和强大了, 被迫使用spring的原因只是在于它的hibernate 集成和事务管理非常不错, 目前找不到可以替换它的更小巧的lib. 想想在spring用它那个恶心的一堆bean定义, 太不够简洁了, 不爽...... 至于action chain, 偶从来不用......, 有什么实际用处么? |
|
返回顶楼 | |
发表时间:2004-10-29
我也只是想到action chain而已。比如说:做audit。
xwork的确很简洁明快。实际上完全不用spring也不是什么大问题。 我最上面提出的那个问题,其实有点理想主义,既然议题是webwork和spring的集成,对于action来说做到spring enabled action,应该是最高的集成度了。 实际上具体项目用得上用不上,各人自己根据情况选择吧。external-ref的本质就是外部注射,如果除了注射之外还需要更多的spring管理的东西,也不介意两次定义action,用spring enabled action是比较合适的。否则用extrernal-ref就够了。 至于你说如果team分为webwork部分和spring部分,那么要改两个配置文件的确很不爽。这个问题我也没好办法。 另外,我也没有测试过二者的实现在性能上是否有区别。 世界上米有十全十美的事情啊~~~ |
|
返回顶楼 | |
发表时间:2004-10-30
曹晓钢 写道 我也只是想到action chain而已。比如说:做audit。
xwork的确很简洁明快。实际上完全不用spring也不是什么大问题。 我最上面提出的那个问题,其实有点理想主义,既然议题是webwork和spring的集成,对于action来说做到spring enabled action,应该是最高的集成度了。 实际上具体项目用得上用不上,各人自己根据情况选择吧。external-ref的本质就是外部注射,如果除了注射之外还需要更多的spring管理的东西,也不介意两次定义action,用spring enabled action是比较合适的。否则用extrernal-ref就够了。 至于你说如果team分为webwork部分和spring部分,那么要改两个配置文件的确很不爽。这个问题我也没好办法。 另外,我也没有测试过二者的实现在性能上是否有区别。 世界上米有十全十美的事情啊~~~ 第二种方法的优点是给Action进行Ioc时只需在spring里进行就可以,不用在xwork里external-ref,所以对于一个Action对应多个操作方法的时候注入的Manager少些,尤其是这多个方法实际需要相同的Manager。 |
|
返回顶楼 | |
发表时间:2004-11-01
intolong 写道 第二种方法的优点是给Action进行Ioc时只需在spring里进行就可以,不用在xwork里external-ref,所以对于一个Action对应多个操作方法的时候注入的Manager少些,尤其是这多个方法实际需要相同的Manager。 这个的确是有这点优势,不过考虑到Xwork里面的Interceptors设计比Spring里面的AOP要简洁易见得多,我大可不必在Spring里面也去做那些事情 而且Readonly的方法也的确很有意思,把一系列服务作为Service注册和使用极大的减少了侵入性,我喜欢,相对耦合比较松。 最近两天正在看Xwork,就看到这个Manager实现了Ioc,正好有疑问Spring和Pico怎么和Xwork结合:),这里就看到了在讨论,真巧 |
|
返回顶楼 | |
发表时间:2004-11-01
不过我不会硬性的使用一个Action实现多个方法,因为每个Action的输入输出都不尽相同,我一般一个Action对应一个方法。
所以我还是选择第一种方法。 |
|
返回顶楼 | |
发表时间:2004-11-01
我支持前者。Action是属于Web层,我们Web层使用了WebWork,就应该把Action由WebWork来管理。它用到的Service,理所当然是在xwork.xml中配置注入。这样思路很清晰,也最符合常规的思维。
|
|
返回顶楼 | |
发表时间:2004-11-01
external-ref方式的另一种测试方法
在xwork.xml中使用一个继承于SpringApplicationContextReferenceResolver的类来定义externalReferenceResolve: public class SpringTestContextReferenceResolver extends SpringApplicationContextReferenceResolver { public SpringTestContextReferenceResolver();{ this.setApplicationContext(new FileSystemXmlApplicationContext("applicationContext.xml"););; } } 嘿嘿,是不是更简单一点? ![]() |
|
返回顶楼 | |
发表时间:2004-12-06
update一下, webwork的email list上有人说用autowire, 偶试用了一下, 比原先的external-ref方式简单多了:
ComponentAutowireInterceptor: public class ComponentAutowireInterceptor implements Interceptor { public String intercept(ActionInvocation invocation); throws Exception { Application.getInstance();.getContainer();.autowireComponent(invocation.getAction(););; return invocation.invoke();; } } public interface Container { public Object getComponent(Object key); throws ComponentNotFoundException; public void reload();; public void autowireComponent(Object bean);; } public class SpringContainer implements Container { private ApplicationContext applicationContext; public SpringContainer(ServletContext servletContext); { this.applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);; } public SpringContainer(ApplicationContext applicationContext); { this.applicationContext = applicationContext; } /** * @param key * component class type or component name * @return @throws * ComponentNotFoundException */ public Object getComponent(Object key); throws ComponentNotFoundException { if (applicationContext == null); throw new IllegalStateException("Spring Application context has not been set");; if (key == null); throw new ComponentNotFoundException("The component key can not be null");; if (key instanceof Class); { String names[] = applicationContext.getBeanDefinitionNames((Class); key);; if (names == null); throw new ComponentNotFoundException("The container is unable to resolve single instance of " + ((Class); key);.getName(); + ", none instances found");; if (names.length == 0 || names.length > 1); throw new ComponentNotFoundException("The container is unable to resolve single instance of " + ((Class); key);.getName(); + ", number of instances found was: " + names.length);; key = names[0]; } return applicationContext.getBean(key.toString(););; } public void reload(); { close();; ((AbstractApplicationContext); applicationContext);.refresh();; } public void autowireComponent(Object bean); { ((AbstractApplicationContext); applicationContext);.getBeanFactory();.autowireBeanProperties(bean, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, false);; } public void close(); { ((AbstractApplicationContext); applicationContext);.close();; } } |
|
返回顶楼 | |