struts1 vs struts2

struts1和struts2现在项目应用的情况如何?

比例是多少呢?想了解一下struts2的现状如何.

谢谢

STRUTS1的人可以很容易的迁移到STRUTS2。
STRUTS2相对于STRUTS1来说，
在测试和开发效率上比STRUTS要好很多

个人观点：Struts2是被Webwork强奸的产物，说白了，是Webwork妄图利用Struts1的巨大市场人气推销其奇怪的产品：struts2将表现层搞得过于复杂，如果再加入AJAX，表现层简直喧宾夺主，抢了业务层风头，个人认为是垃圾，我宁可转JSF/SEAM或Tapestry都不会升级到Struts2:

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

Struts2了解的不多，不过我对它的感觉也不是太好，简单-简单--(复杂)-->强大 失去了软件组装的意义

Webwork本来挺好的，结果搞个Struts2。真的好恶心！

从市场占有情况来看：struts2 in Action 于2008年5月1日刚刚出版，可见，在当前情况，Struts2市场应用根本无法与Struts1相比，当然也无法与JSF相比，我看就是算上以前webwork，勉强和tapestry持平吧。


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

看看struts2的配置：
<package name="example" namespace="/example" extends="struts-default">
<action name="HelloWorld“
class=“sample.HelloWorld">
<result>/HelloWorld.jsp</result>
</action>
</package>

很明显虽然比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修改过]

国产表现层框架easyjweb，宗旨也是追求大道至简，banq可否评价下？
把jdon的思想借过去，这个框架实现一个模型的CRUD和批量查询只须一个action，这得益于对页面的约定，剔除了类似sturts的页面跳转配置，代码示例：


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;
	}
}

如果用这个框架来改写jdon框架，似乎可以做到在表现层更加简捷，当然，和jsf,tapestry这些后期之秀一样，easyjweb的性能比不上struts1，banq老师的意见？



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

oojdon的帖子有些文不对题，我们这里讨论的是struts1 vs struts2，不是讨论所有表现层框架区别，凡是和Struts无关的不要在这个帖子讨论，谢谢配合。

我先回复几句：你有不同意见请开新贴继续讨论：
你说“这个框架实现一个模型的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要灵活细腻多：
<h:commandButton value="Login" action="loginAction"/>

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

<navigation-rule>
<display-name>login</display-name>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>loginAction</from-outcome>
<to-view-id>/welcome.jsp</to-view-id>
</navigation-case>
</navigation-rule>

这就是JSF消灭Action的方式，loginAction只是一个名称，Jdon框架虽然也消灭了Action，但是没有JSF这么简单，因为依赖Struts，所以，在struts-config.xml中配置一下框架中缺省Action：
<action path="/loginAction" type="com.jdon.strutsutil.ModelViewAction" scope="request">

其中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修改过]

没有实际应用过Struts2(Webwork2)的请不要想当然。
Webwork2的精髓在于TypeConverter、Ognl、极具扩展性的插件机制、UI模板、。
至于所谓的无Action的JSF，BackBean是什么东西？我觉得不能因为名称称作Action便去反对，改个名字就是先进。
另外这里Action并不需要去继承ActionSupport，这只是为了方便使用而提供的，好比Jdon的ModelViewAction。这里的action完全是POJO，可用Spring等任意IOC框架来管理。
另外配置文件只是一种选择，Webwork2完全支持注解方式，甚至使用缺省约定的惯例优先即可。
虽然Webwork2本身有Inteceptor和IOC机制，抢了部分的Spring的饭碗，但是这是在Spring出现以前就遗留下来的，可以说是很先进的理念，只不过重点还是MVC而不是IOC，所以这方面的表现不如spring，而且目前完全可以不用。
我是比较反对JSF和Tapestry的UI组件模式，我觉得发展方向应该是UI逻辑和数据分离，browser端使用RIA实现UI，而Server端只提供数据和业务逻辑。事件驱动的UI组件应该在Browser端实现而不是被JSF包装起来搞的性能极差。
[该贴被suzhj于2008-05-29 16:32修改过]

另外感觉banq有点自卖自夸的意思，处处看出来字里行间都透漏着Jdon框架理念是最优秀的意思。
表现层本来就是复杂的是最难解决的，struts2也没有抢业务层的风头，难道业务层能处理复杂的表现层逻辑吗。
这也是为什么表现层框架远远多于其他层框架的原因。其他层像spring、hibernate都是独领风骚，但是表现层却百家争鸣。

>Webwork2的精髓在于TypeConverter、Ognl、极具扩展性的插件机制、UI模板
这些精髓有几个是拿得上桌面的呢？Struts1.x的简单Ognl就够用了，Ognl太复杂就有SQL脚本之嫌疑，难于理解和维护，强大Ognl在TapestryN多年前早就为其特点，而且和Tapestry的事件触发结合，非常完美，所以Tapestry非常适合做工作流软件，从Struts2的努力中看出它也想从中分一杯羹。

我向来重视扩展性，就拿“极具扩展性的插件机制”，真是因为“极具”就是过分了，有人提出扩展性两面性讨论，其实也反应了设计过度的问题：
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使我彻底的从get set中解放出来。

所有的框架都想从对手那里分一杯羹吧！
极具扩展性的插件机制，对我来说是很有必要的，是很适度的设计。
"发展方向应该是UI逻辑和数据分离"这并不是说现阶段完全能实现，目前最佳实践是不同的表现形式使用不同的表现层Result，比如我想要html那就返回html的Result，想要json/xml/pdf/exl/report/img/txt/word等等都可以。目前的Browser端功能限制还是很大，所以还是需要Server端做些事情的。所以这方面提供良好的扩展性是非常好的，而且并不复杂。Struts2在这方面是状元，而且它并不试图实现所有的技术，只是提供良好的扩展性来更容易的包容更多的技术。

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

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

一个框架应该只做好它应该做的事，弄个拦截机制放在view实在感觉不出有什么好。
struts1本身立足于MVC，提交一个表单动作，并不把web组件放在一个高度去处理，这点和JSF就不同了，JSF纯粹就是view层次的。
如果struts1能够再简化些（formBean，action-execute(...)），配置再少点，不要弄太多的webwork那套机制，应该会更好吧。

下页