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

你可能感兴趣的:(jsp,python,struts,validation,tapestry,web框架)