struts1 vs struts2

相关讨论：
http://www.jdon.com/jivejdon/thread/33821.html

struts2 in Action英文版下载
http://www.quanpc.com/15656/EJB.aspx

看看struts2的配置：


/HelloWorld.jsp

很明显虽然比Struts1少了forward配置，但是多了一个父集更重要的配置package，无疑增加复杂性。

Struts2的Aciton需要继承ActionSupport，这个ActionSupport可以做字段属性：
public class HelloWorldAction extends ActionSupport{
private String message;
public String execute() throws Exception{
...}

..}

虽然execute方法比Struts1简单了，但是由于可以有message这样的字段属性，其实增加性能风险，在我当前编程习惯中，我已经养成缺省尽量不要做字段属性，一旦决定有字段属性要慎重反复考虑，从业务角度确认是不是其天然属性，象Struts2这样任何东东都可以做其字段属性，根本没有任何设计考虑，相当危险，滥用下去会造成内存性能风险。总之这个很违反我的口味。

相反，JSF则比较简洁，将Action嵌入了JSP中，也就没有专门的Action类，属于消灭Action，我觉得这是一个方向，我在2004年的Jdon框架中，对Struts1.x封装中，也就是继承消灭Action的思路，所以，从这个角度来说，JSF更符合我的口味。

Struts2比Struts1虽然实现了细枝末节的简化配置，但是却增加了多余的看似更复杂的配置，所谓按起了葫芦飘起了瓢。其实从这里也可以看出，Struts2只是webwork改头换面的一个产物，其核心还在Struts2的xwork.jar包中，而xwork.jar显然是webwork的工作包。

你们不是嫌Struts1配置复杂吗？我给你一个配置简单的，但不是原来Struts1核心思想的拓展和升级，而是换了一个核心给你，这有点强买强卖吧？群众的眼睛是雪亮，作为消费者和使用者，如果我们再这样被他们这么忽悠，未免太...

[该贴被banq于2008-05-29 11:49修改过]

public class PersonAction extends AbstractPageCmdAction {
        /**
          注射业务bean 
        */
	@Inject
	private IPersonService personService;

	public Page doInit(WebForm f, Module m) {
		return go("list");
	}

 //通过地址栏命令list,new到达约定的list.html,new.html页面
	public void doList(WebForm form) {
		List<Person> list = this.personService.findAll();
		form.addResult("list", list);
	}

	public void doSave(WebForm form) {
		Person p = form.toPo(Person.class);
		this.personService.save(p);
		go("list");
	}

	public void doNew() {
		page("edit");
	}

	public void doEdit(WebForm form) {
		Long id = new Long(form.get("id").toString());
		Person p = this.personService.find(id);
		form.addPo(p);
	}

	public void doDelete(WebForm form) {
		Long id = new Long(form.get("id").toString());
		this.personService.remove(id);
		go("list");
	}

	public void setPersonService(IPersonService personService) {
		this.personService = personService;
	}
}

[该贴被oojdon于2008-05-29 12:23修改过]

我先回复几句：你有不同意见请开新贴继续讨论：
你说“这个框架实现一个模型的CRUD和批量查询只须一个action“”，但是，Jdon框架实现一个模型的CRUD，一个action都不需要。，所以，想不出你怎么能得出：“如果用这个框架来改写jdon框架，似乎可以做到在表现层更加简捷”？一个不要写任何Action，一个需要写一个Action，到底谁更加简捷？

你例子中的PersonAction 和struts1的动态Action看不出有何区别，Struts1的Action也可以放很多方法在其中，所以，充其量这个框架易用性和struts1x打个平手(除了DI注射)；而Jdon框架则是在Struts1x基础上优化，消灭了Action

我们再看看JSF/Tapestry是怎么消灭Action的，JSF是类似Swing的事件驱动，可以为界面中每个元素添加一个Action，而不是Struts那样一个表单对应一个Action，很明显JSF要灵活细腻多：

这句就会commandButton这样一个按钮添加一个loginAction的激活事件。而你不必专门编辑一个loginAction，可以通过配置直接导向View一个jsp:

login
/login.jsp

loginAction
/welcome.jsp

这就是JSF消灭Action的方式，loginAction只是一个名称，Jdon框架虽然也消灭了Action，但是没有JSF这么简单，因为依赖Struts，所以，在struts-config.xml中配置一下框架中缺省Action：

其中com.jdon.strutsutil.ModelViewAction就是缺省Action，可以适合大多数CRUD流程。相当于Jdon框架抽象了CURD的Action方法，具体使用时，自己不要写任何Action，只要用这个缺省Action就可以。

所以，就发展方向，JSF/Tapestry无疑是对的，对于表现层框架：MVC是基本，事件驱动是方向。

关于Struts2实质是webwork的证明，InfoQ早就用“WebWork (Struts 2) In Action”来代指Struts2 in Action：
http://www.infoq.com/presentations/struts-2-webwork-pat-lightbody

相关帖子：
表现层框架Struts/Tapestry/JSF架构比较
http://www.jdon.com/artichect/sjt.htm

Struts2案例开发：
http://www.roseindia.net/struts/struts2/struts-2-format.shtml
[该贴被banq于2008-05-29 15:23修改过]

我向来重视扩展性，就拿“极具扩展性的插件机制”，真是因为“极具”就是过分了，有人提出扩展性两面性讨论，其实也反应了设计过度的问题：
http://www.jdon.com/jivejdon/thread/34128.html

在表现层我们需要什么扩展性，我同意楼上"发展方向应该是UI逻辑和数据分离，browser端使用RIA实现UI，而Server端只提供数据和业务逻辑"观点，但是这个观点和Struts2提供的这个扩展性是背道而驰的，Struts2作为服务器端的一个表现层框架，要那么复杂做啥呢？

其实我们就需要MVC将UI逻辑和数据分离即可，剩余的我们都是基于html在browser端实现即可，这些都和你服务器端表现层极具扩展性的插件没有关系或者关系不太大。

看看Struts2中那么plugin.jar，好像可以把全世界表现层技术都纳入其中，越是这样，我就越反感它，就像楼上看到我谈Jdon框架就反感一样。我的经验告诉我只能相信专业状元，而不是所谓全才状元。

再看看Struts2复杂的引入拦截器Inteceptor这样AOP，AOP在业务层做做还可以，表现层本来就有一个ServletFilter已经能够应付大多数拦截器任务，如果使用者在表现层实现拦截器，我看是诚心鼓动用户把开发重点放在表现层，而不是业务层。

>事件驱动的UI组件应该在Browser端实现而不是被JSF包装起来搞的性能极差。
事件驱动是一个方向，至于是象JSF那样包装起来，还是使用AJAX都值得试验，可能后者更适合一些，这些都是次要的，关键是：如果我们的界面不实现事件驱动，我们的Browser就不可能完全替代专有语言开发的胖客户端，你看看J2ME+Polish的客户端开发起来多么方便，一个Form继承以后，只要实现事件激发的commandAction，各种命令只要放入这个UI container就可以,其余界面展现只要用CSS实现就可以，这才是高效率的表现层技术啊. 我相信将来在B/S结构中会出现这样好的事件驱动框架.

[该贴被banq于2008-05-29 18:09修改过]
[该贴被banq于2008-05-29 21:36修改过]

Struts2引入拦截器Inteceptor这样AOP，上面说过这是历史原因，开始没有现成的优秀易用的AOP框架，现在当然是完全可以使用Spring来替代的。表现层也是需要拦截器的，Filter与Inteceptor拦截的目标不同，用户当然可以根据情况选择使用哪个。

事件驱动是一个方向，我很赞同。但JSF、Tapestry的方式还有待商榷吧，至少现在我不认同，要是10来年前出现那是非常好的。