一定要选择单一技术吗?

将某一特定框架作为应用程序架构是个具有潜在风险的决定,原因是以后再作改变可能要付出昂贵的代价。同时,随着可供我们使用的技术的不断发展,以及新技术的不断实用化,我们希望在不浪费以前所有投资的情况下,能把这些新技术融合到现有的应用程序中去。因此,选择基础技术(如 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/

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结