一些非python的web框架的比较

Blog好久没有更新了, 最近一直忙于一个新项目,在这个项目中尝试很多新的做法,准备收集一下放上blog来,这里先放一篇关于Web框架的,基本是老调重谈了. 该文写于4月,主要是为了和朋友讨论问题,有些地方可能不正确

	Struts	JSF	Tapestry	ASP.NET
Architecture	跳转模型 MVC	跳转模型 Front Controller+组件化编程	页面模型 Page Controller+组件化编程	页面模型 Page Controller+组件化编程
Programming Model	业务逻辑： Struts1中需要继承基类；Struts2是POJO的模型； 页面逻辑： 有很不同实现，可以是JSP，也可以是通过模版引擎渲染。	业务逻辑： POJO的编程风格； 页面逻辑： 主要是JSP，也可以用HTML风格。	业务逻辑： Taperstry4需要继承基类；但Taperstry5就是POJO风格； 页面逻辑： 普通的HTML。	业务逻辑： 需要继承基类； 页面逻辑： 类似JSP，但不同的是，该页面实际是业务逻辑类的子类。
Request Process		由官方定义的六个步骤组成；	取决于Engine Service。	由官方定义的15个步骤组成。
Navigation	Path和Action绑定，需要配置文件解析。	通过faces-config.xml配置文件完成。	URL是全局的，没有额外的配置文件； 除非显式跳转，所以行为都在本Page上。 而跳转分两种： 1. DirectLink写在页面上 2. 在代码逻辑中定义页面跳转逻辑。	同Tapestry类似。
Event handling	无	页面定义事件发起；两种方式参数传递方式：一种分离传递；另一种通过FacesContext。	页面定义事件发起；直接赋予参数，没有参数个数限制；除此外还有内置的生命周期相关的event	类似Swing的事件控制方式。
Component State	无	没有状态维护机制，每次request都从建组件。	提供组件状态的维护机制。	提供组件状态的维护机制。
Component Dev	无	基于JSP Tag的开发方式。	开发方式类似Page, 逻辑代码和页面分离，页面输出使用HTML。	开发方式类似Page；逻辑代码和页面分离；页面输出可以复用已有的组件
View	有很不同实现，可以是JSP，也可以是通过模版引擎渲染。	主要是JSP，也可以用HTML风格。	HTML	类似JSP页面。
Validation and Conversion		提供了多种方式支持，但客户端验证支持不好，同时在form一级的支持不好，通常需要项目自己定制。	同样提供多种方式支持；此外提供客户端的Validation；天然地支持form一级支持。	类似Tapestry。
I18N	较好的支持。	较好的支持。	很好的支持，额外提供预览功能。
Testability	Struts1的测试不容易，Strut2测试容易简单。	测试支持简单容易。	Tapestry4的测试不容易，不过Tapestry5的测试可以很简单。	不容易测试。
Extensibility		良好	良好	良好
Industry Momentum	广泛使用，目前各种资源都不错。	JSF业界标准，业内厂商支持会比较多，不过未必不会出现EJB2的结局。	应用范围小于Struts，之前的版本学习曲线太高。	微软地主老财，有大把的钱；此外，大量的第三方公司提供支持。
Migrate		从Struts迁移不难；	从Struts或者JSP迁移难度较大些。

因为工作原因,最近一直在使用Spring Web Flow,与之上几个Web框架对比优点是:
1. 页面流程明确, 除去JSF外,其它几类框架要明确获取页面流程信息并不容易. 对于企业开发来说,这点其实蛮重要的. 一般的互联网网站没有特别的好处.
2. 不需要再写Action等Web控制类. 虽然Struts2,JSF和Tapestry都是POJO了,但依然存在属于Web层范畴的类,而Spring Web Flow不需要,逻辑写在Flow文件中, 直接访问Service对象,获取Domain Model(我们还同时省略了VO). 当然这点可能有同学持反对意见.仁者见仁了!
3. Spring Web Flow提供单元测试能可以容易覆盖页面流程了.