（原作在www.webpagev.com)
开发框架的选择，始终是个仁者见仁、智者见智的事情。尤其是Web层的开发框架，数量非常 |
| 多，而且各有特色，如：Struts、WebWork、Spring MVC、Tapestry、JSF、……等等。 |
| 下面先来看看为什么要使用Web开发框架 |
|
一：使用框架的必然性
|
| 框架，即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的混杂物，多半是没有办法的，更不要说还有一些内容是 |
| 动态生成的，美工就更不可能搞定了。还是得开发人员上阵，按照美工给的模版，开始添加Css：class、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：选择开发框架另外要注意的一点就是：任何开发框架都不可能是十全十美的，也不可能是适应所有 |
| 的应用场景的，也就是说任何开发框架都有它适用的范围。所以选择的时候要注意判断应用的场景和 |
| 开发框架的适用性。 |