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提供单元测试能可以容易覆盖页面流程了.