三、原则上所有异构的信息系统都存在无缝衔接的内在需求。传统的搜索引擎系统就是一种典型的封闭结构，没有真正无缝的外部接口。伯纳斯·李所推动的语义网和web化的SOA在本质上一致，很好的结合起来双方力量可以倍增，语义网属于从网络底层推动“无缝衔接”的努力， 但是在这一技术方面的努力之外，还应该涌现出更多在人性、用户方面推动SOA的努力。

    四、SOA改变了软件的概念。软件原来传统的底层部分被改造为真正工具性的事物，而广义化的软件概念中“服务和任务”成为核心；软件不再是组件、单元、数据库等的加和，而是对于任务和服务的回应，因此服务之间的松耦合异常重要和活跃。随着概念的改变，软件业将重新洗牌。竞争规则改变很大，程序、代码、结构次要化，数据、任务、外部接口更加重要，文本数据可能成为以后SOA的主要对象。 

    五、SOA侧重提供与不同任务的标准化服务接口，其水平高低应该取决于双方的可理解性、可分解性、可交互和互动性。从代码和数据，到结构的技术升级，将进行新的升级，以结构升级入手，寻找比结构更重要的，诸如函数调用、数据响应、结构自适应等。其中，最大的难点应该是互动如何改变参与者的状态，这也是最刺激的地方。

    六、SOA作为第三代软件架构标准，如果与web和3G结合，将大大拓展软件行业的空间，软件可以拥有自己的渠道了，软件加强了自身的力量。

    七、SOA真正付诸实施不是一两家商业力量的事情，他属于一项社会化的技术就年百微工程，需要整合大量的资源，需要有坚强的平台，需要建立商业力量和社会力量的共同利基，需要寻找现实和未来的平衡点。SOA的价值目前主要还是在理念方面，可以触类旁通的引用到很多其他技术领域；SOA让信息和技术更加自由、开放、共享，可以盘活更多的商业数据和技术资源，产生新的价值。同时，SOA需要做出大量的垂直标准，不同领域的差异性可能比较大，虽然他们具有共同的SCA底层。

    八、SOA是商业信息系统的现有资源为基础提供低门槛的接口升级方案，让客户之间的商业沟通更加自由灵活，同时降低面对变化的任务和服务的沟通对话成本，这一目标是通过基于服务和任务的思维和文化理念层次的结构调整实现的，超越了仅仅基于技术和运用的结构调整方案。

随着Browser/Server模式的日渐流行，很多操作都是在浏览器环境下的网页上完成的，并不是只有失效的链接和意外的出错才会使操作者感到烦恼，即便是一次完整的成功操作过程，也可能因为操作的繁复性过高或者使用上的不方便而给操作者带来不愉快的体验。

本文试图阐述WEB交互页面设计的一些指导性原则，这些原则有利于避免发生不愉快的操作体验。这些原则是用户友好性的，是在完成同一种操作要求下，使用户最感到轻松、简单、舒适的WEB交互界面设计原则。我们假定我们讨论的WEB页面都是功能正常的，符合美学观点的。需要说明我们讨论的原则可能会和设计上的美学观点以及既有的功能设计有所冲突。如果发生这种情况，基于“实用的就是美的”观点，我们会建议您酌情放弃原先的美学观点与功能设计。

1． 输入控件的自动聚焦和可用键盘切换输入焦点

使用JavaScript实现页面加载完成后立即自动聚焦(focus)到第一个输入控件。可用TAB键（IE缺省实现）或方向键切换聚焦到下一个输入控件。

输入控件指WEB页面表单(<form>)中显式的，需要用户进行修改、编辑操作的表单元素。对于这些控件，如果没有自动聚焦操作，不可避免的出现一次用户鼠标定位操作（如果用户此前处于键盘输入操作状态或鼠标定位后需要进行键盘输入操作，实际上是键盘鼠标切换操作）。如果鼠标定位后需要进行键盘输入操作，如果不能键盘切换输入焦点，那么不可避免的在切换输入焦点时需要反复的键盘鼠标切换操作，这是很繁琐的。

如果实现了页面加载完成即自动聚焦到第一个输入控件，并且可以键盘切换输入焦点标定位操作，那么对于用户来说整个页面的输入操作可能都不需要鼠标操作，或次数较少，这是一种便利。毕竟频繁的键盘鼠标切换操作是比较累人的。

对于有输入栏的对话框或网页，在不干预的情况下就应将当前控制焦点定位在待输入的输入栏上；如果输入栏在一般情况下不需要更改其中的内容，则应直接将焦点定在“确定”按钮上；在几个输入栏之间应支持tab，shift+tab切换操作，“确定”和“取消”应该是切换操作的终点，与具体所在位置无关。

2．   可用Enter（或Ctrl＋Enter）键提交，确保和点击提交按钮的效果是相同的

不要在提交按钮上加入onClick=”…”这样的JavaScript代码。

用Enter键提交页面是原则1的自然延伸，而且这也是浏览器所缺省支持的。只所以单独列出来是因为实际上有些设计者设计的页面不能达到这种效果，结果导致使用Enter键提交和点击“确定”按钮提交带来的效果不一样。大部分情况下是设计者在“确定”按钮上加入了onClik=”…”这样的代码，通过点击“确定”按钮后，会执行一段JavaScript代码，比如对某些hidden类型的input元素设值。而使用Enter键提交时就不会执行这段代码。

正确的做法是把这段代码移到表单标签<form>中，以onSubmit=”…”属性引入。

对于<textarea>表单元素，它会消耗Enter键，因此会使得Enter键提交失效。可以引入JavaScript代码捕捉Ctrl+Enter复合键，一旦捕捉到即执行表单的submit()方法。对于需要频繁提交的场合，比如BBS上，这种代码是很有必要的。

3． 鼠标动作提示和回应

对用户的鼠标定位操作，当移动到可响应的位置上时，应给予视觉或听觉的提示。

动作回应的最简单形式就是鼠标ICON变成手状。浏览器只对具有href属性的HTML标签会自动进行这种变换ICON的行为。对于没有href属性（或没有设置href属性）的标签，可以通过JavaScript设置style属性的cursor为hand。

目标区域发生变化是更为主动的响应形式。当鼠标指针移到目标区域，此时指针图形改变或文字颜色发生改变均能较大的减轻用户搜索定位目标区域的注意力负担。在按钮上增添直观的图形，尽可能的增大按钮面积；按钮间保持适当的距离，太近增加了用户区别它们之间界限以防误操作的负担，太远增加了用户搜索定位按钮的负担。

4．尽可能早的在客户端完成输入数据合法性验证

输入数据的合法性检验应该在客户端使用JavaScript进行验证。除非验证只能在服务器端完成，否则验证工作应在最早能完成的情况下进行。

在客户端完成数据合法性验证，可以避免一次服务器请求和回复通讯，这种通讯是需要用户等待的，如果用户等待很长时间后从服务器返回的结果提示出现的错误是在输入时即可发现的，那么这种设计就是不友好的。诸如密码长度限制，用户名允许字符限制等等，显然应该在客户端提交前就应该进行验证。

5． 根据应用场景决定在表单页面和提交后返回页面间是否使用中间过渡页面

根据应用场景，决定是否显示接收表单页面（表单页面和提交后返回页面间的中间过渡页面），以及使用何种方式显示接收表单页面。

表单页面和接收表单页面是大部分WEB交互操作赖以实现的配合模式。关于表单页面和接收表单页面的相互关系的设计，要做如下几个方面的考虑。

一，对于需要频繁操作的场合，从操作便利和快捷性出发，尽可能的减少服务器和客户端交互次数，应该避免使用中间过渡页面。提交完毕直接返回原来的表单页面或默认页面。在这种情况下要考虑到数据安全和可恢复性。

如果因为用户输入的数据不合格，需要重新输入，那么，去除中间页面，把错误信息直接显示在原表单页面上的设计方式，将是最简洁的处理方式。用户只需要根据错误提示进行更正即可。当然这样做稍微增加了编程负担。在表单接收页面上需要包含原表单页面的内容，而且输入数据项都必须用服务器端代码或客户端JavaScript设置成用户输入的值。为了开发快捷，可以这样做：表单页面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下流程完成原来两个页面的工作：

页面脚本初始化

┃

检查“提交”变量是否设置

┠已设置，做数据验证

┃   ┠验证通过－>业务逻辑处理－>使用包含页面方式或重定向方式返回到特定页面

┃   ┗验证不通过－>保存用户输入的数据－>退出表单提交处理到表单页面流程中

┗未设置，做表单页面流程，如有来自提交流程中产生的用户输入数据，则显示出来

其中，使用包含页面方式返回到特定页面可以避免一次客户端重定向过程，比客户端重定向过程还要快捷和稳定一些。但是有些情况下因为代码变量冲突或其他原因，使用包含页面方式可能并不方便，这时候可以使用服务器端重定向技术，在ASP里是Server.Transfer方法，在Java Servlet里是RequestDispatcher.forward()方法。不要使用Response.Redirect或者HttpServletResponse.sendRedirect()这种客户端HTTP重定向方法。不使用中间过渡页面也就意味着用户不能后退浏览原先已经填好的表单页面，因为使用的是同一个URL。所以在验证不通过情况下保存用户输入的数据就是必不可少的。

不使用中间过渡页面带来的另一个问题就是使用包含页面方式或服务器端重定向方式返回会使得URL和页面内容不能一一对应。对于用户可能会直接用这个URL（会收藏这个URL）访问返回页面的情况，他会发现实际上到达的是表单页面，不是他想要的那个返回结果页面。所以，去除中间过渡页面，确实会带来URL和内容含混不清的情况，因而不适合需要URL和页面内容一一对应的场合。

二，从技术角度考虑，使用中间过渡页面能保证URL和页面内容一一对应，简化页面开发工作。

为了保证页面内容总是和固定的URL联系起来，必须使用客户端重定向：

           提交                   业务逻辑处理  （中间过渡页面）

表单页面――――－>接收表单页面―――――――――>显示处理结果―――>客户端重定向到特定页面

客户端重定向分几种情况：1，使用HTTP Header重定向，Location:http://www.netall.com.cn，这种定向是最快的，在窗口一片空白的情况下就迅速访问（GET）另一个页面。这种方式实际上不能显示处理结果，只能说是向第一种快速重定向方式的一种折衷处理；2,HTML标签刷新，<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.netall.com.cn">，这种定向比较友好，在这个页面加载完毕后访问另一个页面。很多设计者把这个作为一个技巧使用，在载入一个大页面前放置一个缓冲页面以避免用户乏味的等待；3，JavaScript重定向。由于是用代码控制重定向，可以做的更灵活。比如根据用户习惯，控制操作完毕后的转向流程。4，被动式的重定向。在页面上放置按钮或链接，由用户手动决定返回到特定页面。这种情况适合于处理结果的显示页面包含相当多的信息，需要用户仔细浏览，而决定下一步的操作。

在使用中间过渡页面的情况下，不能再使用页面过期失效了。否则一旦出现错误，需要用户重新输入表单数据，用户就不能用后退按钮恢复此前填写的表单数据了。除非设计者有意禁止这种恢复。

6． 防止表单重复提交处理

对提交按钮点击后做变灰处理避免在网络响应较慢情况下用户重复提交同一个表单。使用页面过期失效避免用户后退浏览重复提交表单。

有些复杂的应用会导致需要较长时间的等待才会返回处理结果。而在较慢的网络环境中，这种情况更是频繁发生。焦急等待的用户往往会重复点击提交按钮。这种情况是设计者所不希望看到的。

使用JavaScript在点击提交按钮后使按钮失效变灰是一个最直接的办法（根据原则2这段代码应该放在<form>标签里onSubmit=”…”做）。此外，在表单页面上，用服务器端脚本设置HTTP Header的Expires为立即过期可以保证用户没办法使用后退浏览恢复表单页面。注意这样做的代价可能是用户辛辛苦苦填写很长的内容，结果一旦操作失误就没法恢复。所以应该避免在包含<textarea>表单元素的页面上使用页面过期失效。

应该说，更严格的方法是，服务器端脚本就应该具备抵抗重复提交的能力。例如，为这个表单分配一个唯一ID或一个使用一次即失效的验证码。此外，这个表单处理还应具有事务性质，如果表单不被接受，所做的改变还是能恢复的。在金融应用场合，重复提交同一笔交易是肯定不被允许的。能在重复提交中获利的一方总是会想办法绕过浏览器的限制，所以不能依赖于客户端的技术。

7． 页面链接是打开新窗口、使用原窗口还是弹出窗口的原则

一般而言，首页上链接可以使用target=”_blank”属性打开新窗口，而其他页面上的链接都应使用原窗口或弹出窗口。如果链接页面内容相对原页面来说不重要，是附属性质的，可以使用弹出窗口方式。

一般情况下应该使用原窗口，把是否保留原窗口内容的权利留给用户。除非设计者相信原页面是如此重要，在用户发出点击指令后还有使用上的价值，以至于不能被随便更新或覆盖。一般来说，只有首页才会处于这样一个地位，用户在首页上打开一个链接后，一般还会在这个首页上去打开另一个链接。比如首页包含极多链接的门户网站，或者搜索引擎的搜索结果页面。Google.com以前的搜索结果页面上的链接是使用原窗口的，后来他们意识到用户会反复使用这个页面，而改成打开新窗口了。一般的网站如果首页链接不多，就不必使用新窗口，这是用户友好的设计原则。

上述情形的一个极端情况就是新页面内容比起原页面内容的重要性差很多，以至于都未必需要打开一个新页面。这时候使用弹出窗口比较合适。用JavaScript弹出窗口有好几种：一个是window.open()函数。这里有个技巧。应该使用window.open()先打开一个空白窗口，再使用location.replace()用目标页面替换。这样做可以避免在打开新页面的过程中导致原页面失去响应。Window.open()将打开一个新的浏览器窗口进程，因此资源消耗比较大。另一个是由微软DynamicHTML规范中扩充的方法createPopup()。createPopup()可以创建无边框的弹出窗口，消耗系统资源较小。还有一个就是用页面中隐藏的层<div>来模拟一个弹出页面。后两种可以使用JavaScript代码填充弹出窗口内容。如果需要下载网页作为其内容的话，需要微软DynamicHTML规范中的<download>标签。

8． 尽可能少的排列可选项，尽可能少的安排操作步骤

根据用户操作习惯安排尽可能少的操作菜单选项，同时要保证尽可能少的操作步骤。

在不降低功能多样性的前提下减少菜单项和操作步骤是用户友好的设计。要做到这一点很不容易。要从用户出发考虑他们最频繁的操作是什么。正常情况下一个用户需要的操作总可以归类为5个以下的种类，如果出现更多的种类，那一定是没有针对用户兴趣去区分主次。一个用户同时有5个以上的强烈兴趣中心是难以想像的，走马观花似的随意点击浏览的用户，是不大可能在某个种类上进行深入的交互操作的。在这5个种类中，每个种类都可能有若干个可操作的二级种类。如果这些二级操作项是不可见的，那么意味着要做两次选择才能进入可操作页面。这就违背了“尽可能少的安排操作步骤”这一原则。如果使用JavaScript制作二级菜单，避免请求服务器，会好一些。如果二级菜单项总共不超过20个左右，不妨将二级菜单直接显示出来，比如放在左列一字向下排开，这样只需要一次选择到可操作项，更加明了方便。

9． 操作逻辑无漏洞，保证数据是操作安全的

多个页面间的操作和同个页面上的多个操作间的逻辑关系在设计上是安全和严谨的。保证不会出现不被允许的用户操作组合，至少不会因为用户的不适当的操作导致出错。

这最典型的表现则是在页面上广泛采用的所谓联动下拉框设计。一个下拉框中允许的选项受另一个下拉框中的选择而变。另外一个例子是根据选择使表单元素有效或者失效。如果在多个页面间也要维持某种合法性逻辑，那么就需要服务器端脚本的参与。这样会使表单设计跟操作有关，应该说这不是一个好的设计。可以通过变更操作步骤顺序、组合方式来尽可能避免这种情况出现。

操作逻辑的设计既要保证用户任意的输入不会导致错误，也要保证是用户输入的数据能购被安全处理。在Session控制下的表单中输入大幅文字可能会导致超时出错，这时候往往还伴随重定向过程，导致用户的长篇输入荡然无存。用JavaScript提醒用户已超时，请保存输入后重新提交，是一个好办法。某些表单元素如<input type=”text”>接受ESC键清除数据，并且无法撤销，这也是很危险的。在中文输入法中常常使用ESC键清楚输入的码位，一旦不小心多按一下ESC就会使得输入数据消失。因此有必要用JavaScript禁用<input>和<textarea>的ESC键处理过程。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=413028

板桥里人 http://www.jdon.com 2005/04/28

　　以数据库为核心的软件时代已经过去，数据库时代早已结束，当我看到J2EE征途中那么多人在对象和数据库之间彷徨痛苦ing的时候，我想我该出来喊一声了。

　　其实这句话在几年前肯定有人喊过，因为中间件时代的来临，实际意味着数据库时代终结，正所谓一山无二虎：如果你重视数据库，你的J2EE系统就无法完全OO，只有你忽视数据库，你的系统才有可能完全迈向OO，至于数据库性能调优等特定功能都可交由EJB容器或O/R Mapping工具实现。

　　很多年前，包括我自己在内的大部分企业程序员都是从数据库开始我们的职业生涯，最早的是dBase/FoxPro，后来有了 SQL系列数据库, Oracle将数据库时代推向了顶峰。

　　每当有一个新项目时，第一步就是首先设计出数据表结构(Table Schema)，然后开始使用SQL语句实现业务逻辑，这种开发模式一直重复，就是后来加入了DelPhI/VB，他们也只是承担图形显示实现，这种C/S结构带来最大问题是：非常难于维护，修改起来，迁一动百。

　　软件的生命在于运动，当它需要发展时，最棒的软件人员如果对他也束手无策，这是谁的悲哀？

　　现在更多人开始接受B/S结构，但是他们中很多人还没有真正明白为什么需要B/S结构，B/S代表的多层架构才是真正目的（因此，伪多层的B/S系统遍地皆是）。

　　多层架构实际是将以前系统中的显示功能、业务运算功能和数据库功能完全分开，杜绝彼此的耦合与影响，从而实现松耦合和良好的可维护性。

　　一. 从设计上说：由于实现层次完全分离，业务运算功能成为一种中间功能（中间层），它不依赖具体的表现层技术(Jsp/Html applet等)，也不依赖具体数据库技术（Oracle/SQL Server），业务运算功能运行在J2EE应用服务器中，当我们的业务运算功能不再依赖数据库时，是否意味着数据库已经不是重点？

　　二. 当然，多层结构带来了性能问题：客户端访问数据库中的数据时，通常需要经过多个层次，非常耗费性能， 如何尽量减少数据库访问是J2EE应用系统首要解决的问题，使用存储过程并没有解决这个问题，存储过程的执行还是属于后端，并没有缩短客户端请求所要经历的坎坷路途。

　　解决性能问题的根本解决之道是使用对象缓存，现在， 64位CPU提供的巨大内存空间为单台缓存计算提供了硬件基础，更重要的是，这种缓存计算是可伸缩的，通过集群的缓存机制（如JBossCache）， 通过增加应用服务器的数量，可以提高整个业务逻辑层的缓存计算能力，抛弃过去那种为内存斤斤计较的老思维吧。

　　三. 在系统分析之初是否首先需要数据表设计呢？回答是否定的， 以UML为代表面向对象的分析设计方法已经成为强大工具，随着面向模型驱动分析设计（MDA）的普及， 面向数据库分析方法正在逐步被抛弃，拥有深厚传统数据库分析习惯的程序员必须面对和接受这种挑战。

　　纵观整个J2EE系统开发过程，数据库已经从过去的中心位置降为一种纯技术实现，数据库只是状态持久化的一种手段（文件是另外一种实现手段）；什么是持久化？这是相对于内存缓存状态而言，持久化就是当内存断电情况下能永久保存状态数据，但是如果J2EE应用服务器是7X24小时集群运行；几乎永不当机，是否有持久化的必要呢？

　　很显然，数据库已经沦为与操作系统中文件系统同样的层面，以它为中心的时代真的结束了，IBM早期将DB2数据库开源已经强烈向我们昭示这点。

　　对于J2EE初学者来说，尽早抛弃过去的两种影响：过程语言编程习惯和以数据库为中心的设计习惯，从全新的面向对象角度(OOA、OOD和OOP、AOP)来设计开发你的J2EE系统，J2EE设计开发三件宝：Model、Patterns和Framework。

　　以上不只是理论，而是我每天正在做的，如果你也是或赞同请广为传播，唤醒更多彷徨痛苦的初学者。

TSS最近相关文章：

使用AOP组合JBossCache实现对象缓存

OSCache降低数据库负载

使用缓存提高Web应用系统性能

Java企业系统架构选择考量

状态对象：数据库的替代者

DDD(Domain-Driven Design领域驱动设计)实战

讨论