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迁移难度较大些。 |
|
因为工作原因,最近一直在使用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提供单元测试能可以容易覆盖页面流程了.