一定要选择单一技术吗?

--做出明智的业务决策。基于 Java 技术、功能强大的基础技术和工具构建 Web 应用程序架构
时间：2005-06-22
作者：Craig R. McClanahan
浏览次数： 493
本文关键字：JavaServer Faces, JSF, struts, web, 架构 文章工具
 推荐给朋友
 打印文章

将某一特定框架作为应用程序架构是个具有潜在风险的决定，原因是以后再作改变可能要付出昂贵的代价。同时，随着可供我们使用的技术的不断发展，以及新技术的不断实用化，我们希望在不浪费以前所有投资的情况下，能把这些新技术融合到现有的应用程序中去。因此，选择基础技术（如 Web 应用程序框架结构）的评判因素之一就是在新技术变得可用时所选的框架是否包容这些新技术。
Struts 框架从几个不同的方面说明了新技术概念的接受程度。 Struts 与模型层的实现策略无关。在这一层使用任何 Java 技术都是可以的。在控制器层，为了易于定制和专业化， Struts 控制器实现方面的新近创新集中于调整现行的设计实践以使之适用于容器上，尤其是要把复杂的操作分解成易于组合的几部分。与此同时，操作的标准组合使向后兼容性得到了维持。在视图层， Struts 早就基于自定义标签提供了可选的视图层，也是使用类似脚本的表达式来把输入输出绑定到模型层中相应的属性值的早期改革者。随着 JSP 技术的发展， Struts 已包含了它们。
JSP 标准标签库（ JSTL ）的发展引进了一种标准表达式语言语法，它比最初的 Struts 表达式语言更为强大简洁。作为回应， Struts 添加了一组软件通用型的标签库，这些标签库提供了常见的功能，但允许使用那些与 JSTL 标签（现在，随着 JSP 2.0 的出现，可用在 JSP 页面的任何地方）完全相同的表达式。
可插性
JavaServer Faces （ JSF ）的标准化产生了一个愿望（就应用程序架构师而言）：能够在基于 Struts 的现有应用程序的 JSP 页面中使用 JSF 组件。这个愿望正在通过 Struts-Faces 集成库的开发而得以实现。
Struts-Faces 集成库的设计中心是要利用 JSF 中的可插性接口，并在必要时提供软件通用型 JSF 组件，以便现有的应用程序能够在视图层使用 JSF 组件，一次一页，同时对应用程序的控制器层和模型层基本上不作改变。（因此，实现 MVC 结构所鼓励的有意义的分离键值之一；通过使变更仅在一层中发生来在一层中最大限度地降低实施变更的成本。）在大多数情况下，需要的惟一变更是对 JSP 页面自身，以及配置文件中逻辑映射。
一起部署时， JSF 接收并处理每一个请求（就像只基于 JSF 的应用程序中的情况一样）。如果请求发送给服务器只是为了改变某一 UI 组件的状态（例如，在数据表中滚动行，或者在树组件中展开一个节点）， JSF 将在不干扰模型层的情况下，设法改变组件的状态并重新显示当前页。这对视图层的状态变化完全适用。另一方面，如果请求是通过激活提交按钮触发的，则该库集成到 JSF 请求处理生命周期中将导致标准 Struts 请求处理生命周期的调用，包括原来描述的所有行为。
通过经济上可行的迁移来采用这种新技术（因为人们没有时间去彻底重写基于新框架的非平凡应用程序）的可能性对于其现有应用程序是基于 Struts 的开发者和组织来说，显然颇具吸引力。不过，在 JSF 没有提供相应功能（如对客户端和服务器端表单确认的支持）的情况下，它也支持利用 Struts 力量的可能性。
为 Web 应用程序选择应用程序架构时，检查框架适应不断变化的技术的历史应是选择标准之一。
在 Web 应用程序架构的发展过程中，我们希望把注意力主要集中到技术细节上： API 、标准，以及如果用手写代码，代码会是个什么样子。确实，由于若干原因，手写这样的应用程序现在已经变得比较容易了。视图层页面设计者只需知道较少的（或根本不需要知道） Java 语言语法就可以加入动态内容。将动态内容元素绑定到模型层数据所需的语法变得更简单了，而功能也更强大了，并且随着 JSF 的出现，这种语法已经消除了在应用于用户界面的字符串与通常用在模型中的原生数据类型之间进行显式转换的必要性。框架已经可以消除应用程序对自身控制器层进行开发和维护的必要性。编写 适配器类 （如 Struts 中的操作，或 JSF 中的操作方法等）变得简单多了，限制（如需要的基类）也减少了。
可视化
所有这些趋势都有助于提高那些使用文本编辑器之类工具的现有开发人员的工作效率。不过，有非常多的开发人员都更愿意在可以对各种组件进行可视化操作而无需手工编码的环境下进行开发。这样的工具将把开发者从大量通常所需的细节中解放出来，包括从了解 JSP 页面中的 HTML 元素语法到了解配置文件中的 XML 语法的各种事情。
在 Struts 框架投入实际应用的这些年里，很多 IDE 都增加了生成基于 Struts 的应用程序的能力。典型的增值特性包括 JSP 页面的可视化构建、页面导航层次结构的可视化管理、配置文件的透明生成和维护。这样的开发工具大大扩展了潜在的开发人员群体。他们能够基于 Struts 构建出高质量的 Web 应用程序。
今天，我们看到提供 JSF 组件的同类功能的工具已经开始得到使用。从某种意义上说，看到工具的这么快就得到使用并不足以大惊小怪—— JSF 对工具开发人员（其中很多都参加了导致 JSF 产生的专家组）来说设计得很友好，标准组件 API 的出现使组件提供者得以将其组件最大限度地应用于更多工具中。但是，我们也看到 Java 平台作为一个整体的激动人心的时刻的开始——将新的开发人员吸引到 Java 。
全球各地大大小小的组织中，专业的软件开发人员通常以受雇（或签约）方式开发支持该组织核心功能的任务关键型应用程序。但一般来说，开发供内部使用（特别是用于一小部分员工，如一个部门）的软件是信息技术（ IT ）部门的职责，并且几乎在每个环境中该部门都肩负着太多的责任，而开发和维护内部应用程序的人员又太少。因此这类部门中越来越多的员工以及很多工作组都开始亲自学习关于开发 Web 应用程序的足够的知识以创建供内部使用的应用程序。
传统上，这样的开发人员都已经使用了简单的工具和脚本语言，几乎总是在某种可视的开发环境下进行开发。在很多情况下， Java 平台对于这些开发人员来说难于理解或使用，因此他们不太爱用基于 Java 技术的解决方案。不过， Web 应用程序框架的成熟和标准化的 Java API （如 JSF ）的出现，为构建能够满足这些开发人员需要且基于 Java 的工具创造了机会。
Sun Java Studio Creator 是面向这一开发群体的最典型的一个 IDE 工具。 Java Studio Creator 具有使这些开发人员即刻提高开发效率的独特特性：由 JSF 组件构成的 JSP 页面的可视化构建；页面导航规则的可视化构建； JSF 组件到后端数据源的拖放式绑定，这些数据源包括关系数据库、 Web 服务和现有的模型层组件，它们通过 JavaBean 属性来显示信息；每个可视（ JSP ）页面与包含组件引用和事件处理程序的对应的 Page bean 的自动关联，以及轻松访问整个应用程序基础设施的便利方法；在编辑应用程序的可视化视图和相应的源代码之间来回转换的能力。在一个视图中所作的改变将在另一个视图中如实地同步进行。
标准化过程促生了功能日益强大、使用日益方便的 API 。现在，应用程序整体结构的最佳实践概念已被封装到功能强大的框架中，使得开发人员能够把精力集中到应用程序所需的特定逻辑上，而不是内部的仔细推敲上。在可视化的开发工具中，对看似复杂的内部概念提供高度抽象以及使那些已经熟悉了 Java 的人能够更快地创建应用程序的并行发展，为开发新手提供了创建应用程序的能力。基础技术力量不断增长的趋势，以及开发工具的不断提高的易用性，必定会在今后继续下去。决定将 Web 应用程序架构建立在 Java 技术基础之上，现在是将来也将一直是一个明智的业务决策，同时也是一个有利的技术决策。
本文摘自“基于 Java 技术的 Web 应用程序架构的发展”。
原文出处
http://www.fawcette.com/javapro/2005_03/magazine/features/cmcclanahan/

作者简介
Craig R. McClanahan是Sun Microsystems 的一名高级工程师，也是构建 Sun Java Studio Creator 产品的团队中的一名架构师。他在 Web 应用程序架构和技术方面的背景包括担任 JavaServer Faces 1.0 （在 Java Community Process 即 JSR 127 下开发的）联合规范的领导者、 J2EE 平台 Web 层架构师、作为 Tomcat 4 和 Tomcat 5 核心的 Catalina servlet 容器的最早架构师，以及 Struts 框架的最初创建者。
_xyz