Web框架比较

	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迁移难度较大些。