WEB框架总结
2020-03-03 11:47:42 来源：范文大全收藏下载本文
概述
开发框架的选择，始终是个仁者见仁、智者见智的事情。尤其是Web层的开发框架，数量非常多，而且各有特色，如：Struts、WebWork、Spring
MVC、Tapestry、JSF、WebPage3.0......等等。他们各自的优、缺点： 框架使用背景
一：使用框架的必然性
框架，即framework。其实就是某种应用的半成品，把不同应用程序中有共性的一些东西抽取出来，做成一个半成品程序，这样的半成品就是所谓的程序框架。
软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。这样每次开发就不用白手起家，而是可以在这个基础上开始搭建。
使用框架的最大好处：减少重复开发工作量、缩短开发时间、降低开发成本。同时还有其它的好处，如：使程序设计更合理、程序运行更稳定等。基于这些原因，基本上现在在开发中，都会选用某些合适的开发框架，来帮助快速高效的开发应用系统。
了解了使用框架的必然性，下面来看看如何选择，当然我们的话题集中在Web层的开发框架。在谈这个问题之前，先来看看我们在Web开发中究竟需要做些什么工作：
二：Web层开发的工作
在J2EE开发中，分层是基本的思想，3层架构或者多层架构早已深入人心，在这里我们就把目光集中到Web层，看看到底Web层开发做了那些工作：
1：数据展示
Web层需要从逻辑层获取需要展示的数据，然后以合理的方式在页面进行展示
2：人机交互
用户需要从界面上输入数据，在界面上进行按钮点击，进而触发事件，标准的事件驱动模型，然后跟后台进行数据交换，出现新的界面。
3：收集数据，调用逻辑层接口
Web层收到用户的事件请求，需要调用相应的逻辑层接口来进行处理，Web层是不会有任何逻辑处理的。调用逻辑层接口，需要传递参数，这时需要收集用户在界面上输入的数据，然后进行组织，组织成为逻辑层接口需要的数据封装形式（通常都是ValueObject）。
4：根据逻辑层的数据来重新展示页面
逻辑层处理完了，需要返回数据或信息到界面上。这个时候Web层需要根据返回的值选择合适的页面，然后展示这些数据或者信息。
从上面可以看出，Web层开发的主要工作集中在展示上，也就是图形用户界面。这一部分是用户直观感受应用程序的窗口，也是用户要求最多的地方，其表现形式也是最丰富的。
三：Web层开发的步骤
下面再来总结一下Web层开发的大致步骤（也就是需要开发人员做的工作）：
注意：这里讨论的Web层开发，是不使用任何开发框架时候的开发。
1：写页面Html，到底有哪些数据需要在界面上表现
2：每个数据的具体表现形式，如：有的需要表现成为下拉列表，有的需要表现成为单选按钮等。
3：界面表现形式的逻辑布局，所谓逻辑布局是指某些数据的表现形式应该放在前面，某些应该放在后面；某些放在上面，某些放在下面。如：某个请假申请的业务，有请假开始时间和结束时间，很明显开始时间的表现就应该排在结束时间的前面。而美工是负责最后页面的美观，一般美工不能动界面的逻辑布局。
4：完成前面3步，页面的表现形式的大致模样就有了，下面需要来做功能性的开发。第一个就是这些表现形式的值的来源，如：下拉列表显示的值从什么地方来。值的来源方式很多，有数据库中来、固定值、某断程序运行的中间结果、前面页面传递过来等等，当然典型的还是来自数据库。
好了，确定了值的来源，开发人员就要写代码来获取这些值，然后把这些值赋值到对应的表现形式里面。
5：还有一些比较特殊，也就是真实操作的是一类值，但是在界面上显示的是另一类值，比如：数据库中有用户编号，到了界面上就得显示用户姓名，但是所有的操作都是要操作用户编号的。我们把这种情况分做：真实值和表现值，他们有一定的内在联系。这些都是要开发人员去转化和维护的。
6：接下来就应该开发功能性的事件响应了。用户点击了某个按钮或者触发了某个事件，首先是客户端：数据检测、客户端事件处理；然后提交到服务端，服务端要获取到客户端提交的数据，然后调用相应的逻辑层接口来响应。当然如何写逻辑层的实现这里就不去谈论了。
7：逻辑层执行完过后，返回数据和信息到Web层，开发人员还需要写代码去处理，选择哪个页面来显示，如何显示这些数据和信息等。
8：在整个交互的过程中，还必须考虑到如何控制权限，如：某些数据不能显示，某些数据不能编辑等等；同样还需要考虑到消息的配置和国际化等等。这些功能起源于逻辑层，但是实际的控制要到Web层，这些都需要开发人员来控制。
9：完成了上面的开发步骤，页面基本的功能开发就告一段落，接下来开发人员需要考虑页面美观的问题了。大家可能会说：\"不是有美工吗，还需要开发人员干什么？\"。事实上美工多半只能出一个静态页面的美化模版，美工对于一推Java代码和Html的混杂物，多半是没有办法的，更不要说还有一些内容是动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加C：cla、id、style......
10：完成上面的开发，基本页面的开发工作就完成了，最后的一个步骤就是把各个页面有机的组织起来，开发应用程序的整体应用导航框架，通常就是菜单，然后把各个功能页面跟菜单结合起来，形成一个完整的应用。
在这里我们省略了开发期反复的调试过程，仅总结开发的步骤。
四：选择Web开发框架的目的
了解了如果没有框架，我们需要做的工作，这对选择框架有非常大的帮助。
框架，直白点说，就是一个半成品，能够帮我们做一些事情的半成品。
框架的选择，就是看哪个框架最合适，从而减少开发的工作量，提高开发的效率和质量，并有效减少维护的工作量，最终达到节约综合开发成本，获取更多的收益。
五：选择Web开发框架的标准
声明：这里所谈的选择Web开发框架的标准，只是我们的总结和一家之言，并不是放之四海而皆准的真理，请根据您的体会客观的看待我们的总结。
另外：我们这里更多的讨论业务功能性应用程序的Web开发框架。
1：选择能够对我们的开发过程提供更多、更好帮助的Web开发框架
2：Web开发框架的学习一定要简单，上手一定要快，没有什么比使用能得到更深的体会。那些动不动就需要半个月或者一个月学习周期的框架，实在是有些恐怖。
3：一定要能得到很好的技术支持，在应用的过程中，或多或少都会出现这样或者那样的问题，如果不能很快很好的解决，会对整个项目开发带来影响。一定要考虑综合成本，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的办法，通常一个问题就会导致1-2天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发成本嗖嗖的就上去了。
4：Web开发框架结合其他技术的能力一定要强，比如：在逻辑层要使用Spring或者Ejb3，那么Web开发框架一定要能很容易，很方便的与它们进行结合。
5：Web开发框架的扩展能力一定要强。在好的框架都有力所不及的地方，这就要求能很容易的扩展Web开发框架的功能，以满足新的业务需要。同时要注意扩展的简单性，如果扩展框架的功能代价非常大，还不如不用呢。
6：Web开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认。
7：Web开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。
8：Web开发框架一定要是运行稳定的，运行效率高的。框架的稳定性和运行效率直接影响到整个系统的稳定性和效率。
9：Web开发框架一定要能很好的结合目前公司的积累。在多年的开发中已有了很多积累，不能因为使用Web开发框架就不能再使用了，那未免有些得不偿失。
10：选择开发框架另外要注意的一点就是：任何开发框架都不可能是十全十美的，也不可能是适应所有的应用场景的，也就是说任何开发框架都有它适用的范围。所以选择的时候要注意判断应用的场景和开发框架的适用性。 框架测评 JSF
优点：
Java EE标准，这意味着有很大的市场需求和更多的工作机会
上手快速并且相对容易
有大量可用的组件库
缺点：
大量的JSP标签
对REST和安全支持不好
没有一个统一的实现。既有SUN的实现，又有Apache的实现--MyFaces。
Spring MVC
优点：
对覆盖绑定（overriding binding）、验证（validation）等提供生命周期管理
与许多表示层技术/框架无缝集成：JSP/JSTL、Tiles、Velocity、FreeMarker、Excel、XSL、PDF等
便于测试--归功于IoC
缺点：
大量的XML配置文件
太过灵活--没有公共的父控制器
没有内置的Ajax支持
Stripes
优点：
不需要书写XML配置文件
良好的学习文档
社区成员很热心
缺点：
社区比较小
不如其他的项目活跃
ActionBean里面的URL是硬编码的 Struts 2
优点：
架构简单--易于扩展
标记库很容易利用FreeMarker或者Velocity来定制
基于控制器或者基于页面的导航
缺点：
文档组织得很差
对新特征过分关注
通过Google搜索到的大多是Struts 1.x的文档 Tapestry
优点：
一旦学会它，将极大地提高生产率
HTML模板--对页面设计师非常有利
每出一个新版本，都会有大量的创新
缺点：
文档过于概念性，不够实用
学习曲线陡峭
发行周期长--每年都有较大的升级
Wicket
优点：
对Java开发者有利（不是Web开发者）
页面和显示绑定紧密
社区活跃--有来自创建者的支持
缺点：
HTML模板和Java代码紧挨着
需要对OO有较好的理解
Wicket逻辑--什么都用Java搞定
接着，Matt通过采访这些框架的作者，与他们讨论各种开源的Java Web框架，并且突出各个框架的长处、听取框架作者对其他框架的看法，希望借此了解这些框架的未来发展方向。
下列是一些被采访者：
JSF, Jacob Hookom
RIFE, Geert Bevin
Seam, Gavin King
Spring MVC, Rob Harrop
Spring Web Flow, Rob Harrop and Keith Donald
Stripes, Tim Fennell
Struts 1, Don Brown
Tapestry, Howard Lewis Ship
Trails, Chris Nelson
Struts 2, Patrick Lightbody
Wicket, Eelco Hillenius
Matt对采访做了如下总结：
JSF:
如果你想让web应用具有类似桌面程序的功能性，那么JSF的标准规范和大量第三方组件库的支持值得你 信赖。
Spring MVC:
综合了许多不同的技术，这使得它可以被广泛地应用到不同类型的项目中去；它可以被当作web应用开发的一个基础平台。
Stripes:
可以被应用到存在大量复杂数据交互的程序中；有强大的类型转换、绑定和验证功能；可以使管理大的复杂表单以及直接映射它们到域对象变得简单...... Tapestry:
在中到大型项目中，表现突出（当然，你也可以只把它应用到单个页面上），在这些项目中，你可以通过简单地创建新的组件起到杠杆作用。
Struts 2:
通常更适合于那些希望可以真正开始做事并且愿意花费大量时间来学习他们使用的开源工具的小项目组。Struts 2的目标不是那些更喜欢拖放式开发的\"扶手椅程序员\"。
Wicket:
非常适合于这样的内/外部网应用：UI很复杂并且你希望可以充分利用你的开发者资源。
上面的总结，基本是突出了各个框架的长处。然而，哪些又是他们不好的地方呢？ 评价一个框架好坏与否的标准：
Ajax支持
是不是内置了？是否便于使用？
书签能力
用户能否将某个页面收藏起来并且可以方便地返回到该页面？
验证
使用是否简单？是否支持客户端（JavaScript）验证？
可测试性
脱离容器测试控制器，是否足够简单？
提交和重定向
框架如何处理重复提交问题？
国际化
如何支持国际化？控制器利用国际化信息，是否容易？
页面修饰
框架支持哪种类型的页面修饰/组成机制？
社区和技术支持
提出问题，能否被快速地、恭敬地回答？
开发工具
是否有支持这个框架的好的工具，尤其是IDE？
市场需求
学习了这个框架，它能否帮你找到份工作？
岗位数量
在dice.com和indeed.com上，对这个框架技能的需求如何？ 笔者认为这个评价标准，值得大家借鉴。
然后，Matt按照这些评价标准，对各个框架做了以下阐述：
Ajax支持
JSF：没有内置的Ajax支持，需要使用ICEfaces和Ajax4JSF
Stripes：没有对应的类库，支持流输出
Struts 2：内置Dojo，有用于GWT和JSON的插件
Spring MVC：没有对应的类库，需要使用DWR和Spring MVC扩展
Tapestry：Tapestry 4.1中，有内置的Dojo
Wicket：有Dojo和Script.aculo.us支持
书签能力
JSF：可以任意提交--URL甚至不被考虑
Stripes：使用约定，但是你可以不加理会
Struts 2：有命名空间的概念，这使得收藏某个页面并返回变得容易
Spring MVC：允许完全的URL控制
Tapestry：依然存在一些丑陋的URL
Wicket：允许装配（mount）页面/URL
验证
JSF：默认的国际化信息丑陋，但是配置简单
Stripes和Wicket：用Java类进行验证--不支持客户端验证
Struts 2：使用OGNL完成强大的表达式验证功能；只有在Action上指定了规则，才支持客户端验证。
Spring MVC：允许你使用公共验证器--这是一种成熟的解决方案
Tapestry：有健壮的验证功能--不需自定义就有漂亮的国际化信息
可测试性
Spring MVC和Struts 2：允许利用mocks（例如EasyMock、jMock和Spring Mocks）简单地进行测试
Tapestry：测试困难，因为页面类被抽象、具体类被简化
JSF：页面类可以方便地被测试，实际上很像Struts 2 中的actions
Wicket：有WicketTester--一个强大的解决方案
Stripes：有Servlet API Mocks和MockRoundtrip
提交和重定向
解决重复提交问题的最简单方法是：在提交后重定向
Spring MVC：允许你将参数加到重定向URL上
Stripes、Tapestry和Wicket：有\"flash式\"的支持
Struts 2：需要一个自定义的解决方案
JSF：需要一个自定义的解决方案，国际化信息很难加入到页面bean中
国际化
JSTL的标签使国际化变得简单；如何将国际化信息放到控制器类中，还没有一个统一的标准。
Stripes、Spring MVC和JSF：每个地区使用一个资源绑定文件
Struts
2、Tapestry和Wicket：提倡把每个页面/action用到的资源文件分开
JSF：需要在每个页面上定义资源绑定信息
Tapestry：标签比较可怕
页面修饰
Tiles能够用于Struts
2、Spring MVC和JSF中；需要对每个页面进行配置。
SiteMesh能够用于所有的这些框架中（不推荐在JSF、Tapestry或者Wicket中使用）；在设置完成后， 只需要很少的维护。
开发工具
Spring MVC：Spring IDE，但是只做XML校验，不是一个UI/web工具
Struts 2：Eclipse
Tapestry：Spindle，对编码者非常有利
JSF：众多IDE支持，并且做得越来越好
Stripes和Wicket：没有任何官方工具
NetBeans目前支持Struts *、JSF（+Facelets）、Tapestry和Wicket，尚不支持Stripes和Spring MVC
市场需求
Struts 1：需求依然很大并且被广泛使用
Spring MVC：越来越受关注，但大部分是因为Spring框架的一些其他特征
JSF：很快地变得流行起来
Struts 2：正在获得地盘，但是相关的工作机会很少
Tapestry：在过去的数年里，受欢迎程度不断增加
Wicket和Stripes：还是未知数
通过以上的比较，我想大家对在自己的项目中应该选择哪种Web层框架，应该有了更清醒的认识。
最后，Matt列出了一些相关资源，也供读者参考。
Strutshttp://www.daodoc.com
Spring IDE: http://www.daodoc.com
Gaijin Studio: http://gaijin-studio.sf.net
Struts 2http://tapestry.apache.org
http://spindle.sourceforge.net
JSFhttp://appfuse.org
演讲的最后，Matt以一句\"If it works, use it!\"作为结尾，可谓精辟！
通过此文，相信大家可以拨开当前Java Web层框架选用上的\"迷雾\"，见得\"月明\"了。
人人范文网 m.inrrp.com.cn 手机版