基于MVC的WEB应用的开发包括控制层和表现层的开发,其中表现层又包括页面逻辑(指客户端验证,客户端界面动态生成)和页面表现元素(界面),这里,将对两种比较常用的基于MVC的优秀的WEB开发架构WebWork+FreeMarker和JSF进行比较。
WebWork是一种传统的MVC框架,其简单而又不失强大,架构非常灵活、扩展性强,完成最核心的功能也仅通过实现Action接口,而扩展的功能基本上可以通过其拦截器结构完成,另外,从WebWork2开始与ServletAPI的解耦也使其具备比较强的可测试性。然而其缺点也是非常地明显,一方面其用户群比较少,缺少足够文档,另一方面,由于其开发团队与Struts团队合并以WebWork为核心开发新的MVC框架Struts Ti ,WebWork2.2已经是其最终版本,缺乏后续版本的支持,而StrutsTi前途也还是个未知数。
JSF是JCP出品Sun力推的标准,虽然出现较迟但可以说是来势汹汹,大有想要一统MVC的架势。JSF的优点在于其标准,附带而来的好处是丰富的JSF组件可供选择,其另一个卖点是拖拽式的界面开发模式。然而,其JSF本身架构的复杂性足以让人望而生畏,一方面,JSF组件的使用一旦出现问题非常难以调试,而其出错信息往往没有多少有价值的东西,另一方面,一旦标准组件不能满足需求需要独立开发的话,难度非常高。
下面将对这两种技术进行比较:
一、控制层:
1.耦合度
1)与ServletAPI的耦合
两者都可以完全与ServletAPI的解耦,在开发时也都应该尽量避免与ServletAPI的耦合
2)与框架API的耦合
WebWork:所有的控制类必须实现Action接口
JSF:FacesBean不需要继承任何JSF接口。但有时需要与界面元素(譬如列表框)产生耦合,开发时应 该尽量将该部分隔离
评价:这两种技术都是低耦合的,不相上下
2.IOC能力
WebWork本身提供了部分的IOC能力,但功能比较弱,已不被推荐。两者都可以通过与Spring的结合获 得IOC的能力,相对而言,JSF更简单而且提供更多的功能。
评价:不相上下,JSF稍微胜出
3.AOP能力
WebWork:其拦截器功能本身就是一种AOP方式
JSF:可以通过与Spring的结合获得AOP能力
评价:WebWork的AOP能力与WebWork的核心结合地更紧密,WebWork稍微胜出
4.配置
WebWork的配置本身不够简洁,而与Spring的结合更是出现重复的配置情况,相比而言,JSF更简洁
评价:JSF胜出
5.可测试性
WebWork:WebWork本身的简洁和灵活使其具备非常高的可测试性,可以脱离容器测试其控制层的行为
JSF:不清楚,似乎不能脱离容器独立测试配置
评价:似乎是WebWork胜出
二、表现层:
1.组件化
FreeMarker:可以通过FreeMarker的宏能力将一些常用的组件,开发比较简单,但同时,自己开发组件时间和质量上可能无法保障
JSF:JSF本身就是为组件而生,由于其标准化,有丰富的组件可以使用,在项目的前期投入少,不需要专门开发组件
评价:随着项目的开展,组件化的优势应该会越来越明显。在这点上,JSF压倒性胜出
2.可调试性
FreeMarker:FreeMarker本身的出错定位能力非常强,往往出错信息非常直观,但一旦进行组件包装,可调试性将大打折扣
JSF:JSF的组件本身比较复杂,调试性差,往往很难根据出错信息定位出错情况,更多的时候需要依靠经验来解决
评价:FreeMarker稍胜出
3.扩展
FreeMarker:FreeMarker的宏功能非常简单,功能扩展非常方便,但不足之处在于其逻辑表达能力比较差
JSF:JSF的组件的复杂性导致扩展新的功能是一个不小的代价,但Java语言强大的表达能力也使其能开发出复杂的功能
评价:FreeMarker稍胜出
4.表现逻辑能力
FreeMarker+WebWork:在WebWork的最新版本中提供了Ajax的客户端验证能力,但仍然比较原始
JSF:JSF有些客户端验证组件,但总的来说,仍然需要加强
评价:都比较差
5.Ajax
FreeMarker+WebWork:WebWork在最新版本中提供了Ajax支持,但包装暂时还是比较原始
JSF:有各种具备Ajax特性的界面组件存在,同时可使用AjaxAnywhere提供更好的用户体验
评价:JSF稍胜出
从如上的比较可以看出,WebWork+FreeMarker和JSF可以说各有胜场,我的看法是,WebWork+FreeMarker具有更平缓的学习曲线,使用比较简单,在应付小项目和小团队上,略胜一筹;而面向大项目和大团队,JSF的组件化在项目的进展中将发挥更大的作用。
除此之外,JSF的拖拽式的界面开发也是一个卖点,但我的看法是,对于一个熟手来说,其带来的效率上的提高是微乎其微的,此外,一个提供这种功能的IDE,以下两个问题是应该考虑的:
1)对第三方JSF组件的支持
2)自动化生成的代码的维护
WebWork是一种传统的MVC框架,其简单而又不失强大,架构非常灵活、扩展性强,完成最核心的功能也仅通过实现Action接口,而扩展的功能基本上可以通过其拦截器结构完成,另外,从WebWork2开始与ServletAPI的解耦也使其具备比较强的可测试性。然而其缺点也是非常地明显,一方面其用户群比较少,缺少足够文档,另一方面,由于其开发团队与Struts团队合并以WebWork为核心开发新的MVC框架Struts Ti ,WebWork2.2已经是其最终版本,缺乏后续版本的支持,而StrutsTi前途也还是个未知数。
JSF是JCP出品Sun力推的标准,虽然出现较迟但可以说是来势汹汹,大有想要一统MVC的架势。JSF的优点在于其标准,附带而来的好处是丰富的JSF组件可供选择,其另一个卖点是拖拽式的界面开发模式。然而,其JSF本身架构的复杂性足以让人望而生畏,一方面,JSF组件的使用一旦出现问题非常难以调试,而其出错信息往往没有多少有价值的东西,另一方面,一旦标准组件不能满足需求需要独立开发的话,难度非常高。
下面将对这两种技术进行比较:
一、控制层:
1.耦合度
1)与ServletAPI的耦合
两者都可以完全与ServletAPI的解耦,在开发时也都应该尽量避免与ServletAPI的耦合
2)与框架API的耦合
WebWork:所有的控制类必须实现Action接口
JSF:FacesBean不需要继承任何JSF接口。但有时需要与界面元素(譬如列表框)产生耦合,开发时应 该尽量将该部分隔离
评价:这两种技术都是低耦合的,不相上下
2.IOC能力
WebWork本身提供了部分的IOC能力,但功能比较弱,已不被推荐。两者都可以通过与Spring的结合获 得IOC的能力,相对而言,JSF更简单而且提供更多的功能。
评价:不相上下,JSF稍微胜出
3.AOP能力
WebWork:其拦截器功能本身就是一种AOP方式
JSF:可以通过与Spring的结合获得AOP能力
评价:WebWork的AOP能力与WebWork的核心结合地更紧密,WebWork稍微胜出
4.配置
WebWork的配置本身不够简洁,而与Spring的结合更是出现重复的配置情况,相比而言,JSF更简洁
评价:JSF胜出
5.可测试性
WebWork:WebWork本身的简洁和灵活使其具备非常高的可测试性,可以脱离容器测试其控制层的行为
JSF:不清楚,似乎不能脱离容器独立测试配置
评价:似乎是WebWork胜出
二、表现层:
1.组件化
FreeMarker:可以通过FreeMarker的宏能力将一些常用的组件,开发比较简单,但同时,自己开发组件时间和质量上可能无法保障
JSF:JSF本身就是为组件而生,由于其标准化,有丰富的组件可以使用,在项目的前期投入少,不需要专门开发组件
评价:随着项目的开展,组件化的优势应该会越来越明显。在这点上,JSF压倒性胜出
2.可调试性
FreeMarker:FreeMarker本身的出错定位能力非常强,往往出错信息非常直观,但一旦进行组件包装,可调试性将大打折扣
JSF:JSF的组件本身比较复杂,调试性差,往往很难根据出错信息定位出错情况,更多的时候需要依靠经验来解决
评价:FreeMarker稍胜出
3.扩展
FreeMarker:FreeMarker的宏功能非常简单,功能扩展非常方便,但不足之处在于其逻辑表达能力比较差
JSF:JSF的组件的复杂性导致扩展新的功能是一个不小的代价,但Java语言强大的表达能力也使其能开发出复杂的功能
评价:FreeMarker稍胜出
4.表现逻辑能力
FreeMarker+WebWork:在WebWork的最新版本中提供了Ajax的客户端验证能力,但仍然比较原始
JSF:JSF有些客户端验证组件,但总的来说,仍然需要加强
评价:都比较差
5.Ajax
FreeMarker+WebWork:WebWork在最新版本中提供了Ajax支持,但包装暂时还是比较原始
JSF:有各种具备Ajax特性的界面组件存在,同时可使用AjaxAnywhere提供更好的用户体验
评价:JSF稍胜出
从如上的比较可以看出,WebWork+FreeMarker和JSF可以说各有胜场,我的看法是,WebWork+FreeMarker具有更平缓的学习曲线,使用比较简单,在应付小项目和小团队上,略胜一筹;而面向大项目和大团队,JSF的组件化在项目的进展中将发挥更大的作用。
除此之外,JSF的拖拽式的界面开发也是一个卖点,但我的看法是,对于一个熟手来说,其带来的效率上的提高是微乎其微的,此外,一个提供这种功能的IDE,以下两个问题是应该考虑的:
1)对第三方JSF组件的支持
2)自动化生成的代码的维护