??xml version="1.0" encoding="utf-8" standalone="yes"?> 三、原则上所有异构的信息pȝ都存在无~衔接的内在需求。传l的搜烦引擎pȝ是一U典型的闭l构Q没有真正无~的外部接口。伯Ux·李所推动的语义网和web化的SOA在本质上一_很好的结合v来双方力量可以倍增Q语义网属于从网l底层推?#8220;无缝衔接”的努力, 但是在这一技术方面的努力之外Q还应该涌现出更多在人性、用h面推动SOA的努力?/p>
四、SOA改变了Y件的概念。Y件原来传l的底层部分被改造ؓ真正工具性的事物Q而广义化的Y件概念中“服务和Q?#8221;成ؓ核心QY件不再是lg、单元、数据库{的加和Q而是对于d和服务的回应Q因此服务之间的松耦合异常重要和活跃。随着概念的改变,软g业将重新z牌。竞争规则改变很大,E序、代码、结构次要化Q数据、Q务、外部接口更加重要,文本数据可能成ؓ以后SOA的主要对象?nbsp; 五、SOA侧重提供与不同Q务的标准化服务接口,其水q高低应该取决于双方的可理解性、可分解性、可交互和互动性。从代码和数据,到结构的技术升U,进行新的升U,以结构升U入手,L比结构更重要的,诸如函数调用、数据响应、结构自适应{。其中,最大的隄应该是互动如何改变参与者的状态,q也是最刺激的地斏V?/p>
六、SOA作ؓW三代Y件架构标准,如果与web?Gl合Q将大大拓展软g行业的空_软g可以拥有自己的渠道了QY件加Z自n的力量?/p>
七、SOA真正付诸实施不是一两家商业力量的事情,他属于一社会化的技术就q百微工E,需要整合大量的资源Q需要有坚强的^収ͼ需要徏立商业力量和C会力量的共同利基,需要寻扄实和未来的^衡点。SOA的h值目前主要还是在理念斚wQ可以触cL通的引用到很多其他技术领域;SOA让信息和技术更加自由、开放、共享,可以盘活更多的商业数据和技术资源,产生新的价倹{同ӞSOA需要做出大量的垂直标准Q不同领域的差异性可能比较大Q虽然他们具有共同的SCA底层?br />
1Q?服务器负载均衡市场需?br />
随着Internet的普及以及电子商务、电子政务的发展Q越来越多的应用pȝ需要面Ҏ高的讉K量和数据量。同Ӟ企业对在U系l的依赖也越来越高,大量的关键应用需要系l有_的在U率及高效率。这些要求得单一的网l服务设备已l不能满些需要,由此需要引入服务器的负载均衡,实现客户端同时访问多台同时工作的服务器,一则避免服务器的单Ҏ障,再则提高在线pȝ的服务处理能力。从业界环境来说Q如下的应用需求更是负载均衡发展的推动力: 负蝲均衡技术在现有|络l构之上提供了一U廉仗有效、透明的方法,来扩展网l设备和服务器的带宽、增加吞吐量、加强网l数据处理能力、提高网l的灉|性和可用性。它有两斚w的含义:首先Q大量的q发讉K或数据流量分担到多台节点讑֤上分别处理,减少用户{待响应的时_其次Q单个重负蝲的运分担到多台节点讑֤上做q行处理Q每个节点设备处理结束后Q将l果汇总,q回l用Ppȝ处理能力得到大幅度提高?/p>
BIG/IP利用定义在其上面的虚拟IP地址来ؓ用户的一个或多个应用服务器提供服务。因此,它能够ؓ大量的基于TCP/IP的网l应用提供服务器负蝲均衡服务。BIG/IPq箋地对目标服务器进行L4到L7合理性检查,当用户通过VIPh目标服务器服务时QBIG/IPҎ目标服务器之间性能和网l健h况,选择性能最佳的服务器响应用Lh?/p>
下图描述了一个负载均衡发生的程Q?br />
2.负蝲均衡典型程 2.1 通过VIP来截获合适的需要负载均衡的量 2.2 服务器的健康监控和检?/p>
服务?(Node) - Ping (ICMP) BIGIP可以定期的通过ICMP包对后台服务器的IP地址q行,如果在设定的旉内能收到该地址的ICMP的回应,则认服务器能提供服务 服务 (Port) – Connect ECV是一U非常复杂的服务查,主要用于认应用E序能否对请求返回对应的数据。如果一个应用对该服务检查作出响应ƈq回对应的数据,则BIG/IP控制器将该服务器标识为工作良好。如果服务器不能q回相应的数据,则将该服务器标识为宕机。宕Z旦修复,BIG/IP׃自动查证应用已能对客戯求作出正响应ƈ恢复向该服务器传送。该功能使BIG/IP可以保护g伸到后端应用如Web内容及数据库。BIG/ip的ECV功能允许您向Web服务器、防火墙、缓存服务器、代理服务器和其它透明讑֤发送查询,然后查返回的响应。这有助于认您ؓ客户提供的内Ҏ是其所需要的?/p>
扩展应用查证(EAV: Extended Application Verification) EAV是另一U服务检查,用于认q行在某个服务器上的应用能否对客戯求作出响应。ؓ完成q种查,BIG/IP控制器用一个被UC外部服务查者的客户E序Q该E序为BIG/IP提供完全客户化的服务查功能,但它位于BIG/IP控制器的外部。例如,该外部服务检查者可以查证一个Internet或Intranet上的从后台数据库中取出数据ƈ在HTML|页上显C的应用能否正常工作。EAV是BIG/IP提供的非常独特的功能Q它提供理者将BIG/IP客户化后讉K各种各样应用的能力,该功能BIG/IP在提供标准的可用性查证之外能获得服务器、应用及内容可用性等最重要的反馈?br />
该功能对于电子商务和其它应用臛_重要Q它用于从客L角度试您的站点。例如,您可以模拟客户完成交易所需的所有步骤-q接到站炏V从目录中选择目以及验证交易使用的信用卡。一旦BIG/ip掌握了该“可用?#8221;信息Q即可利用负载均衡资源辑ֈ最高的可用性?/p>
BIG/ip已经为测试Internet服务的健h况和状态,预定义的扩展应用验证(EAV)Q它有二U用L面:览器和CLI配置。BIG/IP预定义的应用查:FTP、NNTP、SMTP、POP3和MSSQL?/p>
BIGIP是一台对量和内容进行管理分配的讑֤。它提供12U灵zȝ法数据流有效地{发到它所q接的服务器。而面对用P只是一台虚拟服务器。用h时只记住一台服务器Q即虚拟服务器。但他们的数据流却被BIGIP灉|地均衡到所有的服务器。这12U算法包括: ?strong>轮询QRound RobinQ:序循环请求一ơ顺序@环地q接每个服务器。当其中某个服务器发生第二到W?层的故障QBIG/IP把其从序循环队列中拿出,不参加下一ơ的轮询Q直到其恢复正常?br />
?strong>比率QRatioQ:l每个服务器分配一个加权gؓ比例Q根椐这个比例,把用Lh分配到每个服务器。当其中某个服务器发生第二到W?层的故障QBIG/IP把其从服务器队列中拿出Q不参加下一ơ的用户h的分配,直到其恢复正常?br />
?strong>优先权(PriorityQ:l所有服务器分组Q给每个l定义优先权QBIG/IP用户的请求,分配l优先最高的服务器组Q在同一l内Q采用轮询或比率法Q分配用LhQ;当最高优先中所有服务器出现故障QBIG/IP才将h送给ơ优先的服务器l。这U方式,实际为用h供一U热备䆾的方式?br />
?strong>最的q接方式QLeast ConnectionQ:传递新的连接给那些q行最连接处理的服务器。当其中某个服务器发生第二到W?层的故障QBIG/IP把其从服务器队列中拿出Q不参加下一ơ的用户h的分配,直到其恢复正常?br />
?strong>最快模式(FastestQ:传递连接给那些响应最快的服务器。当其中某个服务器发生第二到W?层的故障QBIG/IP把其从服务器队列中拿出Q不参加下一ơ的用户h的分配,直到其恢复正常?br />
?strong>观察模式QObservedQ:q接数目和响应时间以q两的最佛_衡ؓ依据为新的请求选择服务器。当其中某个服务器发生第二到W?层的故障QBIG/IP把其从服务器队列中拿出Q不参加下一ơ的用户h的分配,直到其恢复正常?br />
?strong>预测模式QPredictiveQ:BIG/IP利用攉到的服务器当前的性能指标Q进行预分析,选择一台服务器在下一个时间片内,其性能达到最佳的服务器相应用Lh?被bigipq行?
二、SOA更加接近比尔·盖茨“信息在你指?#8221;的愿景,l互联网打破信息和数据流动的壁垒之后Q致力于打破软gE序在不同商业组l现有的机构pȝ之间q行无缝衔接的障,而IBM、RACLE{巨人定制的SOA国际标准SCA已经为此构造出单性的底层技术标准基?/p>
八、SOA是商业信息系l的现有资源为基提供低门槛的接口升ҎQ让客户之间的商业沟通更加自qz,同时降低面对变化的Q务和服务的沟通对话成本,q一目标是通过Z服务和Q务的思维和文化理念层ơ的l构调整实现的,越了仅仅基于技术和q用的结构调整方案?/p>
1. 客户发出服务h到VIP
2. BIGIP接收到请求,数据包中目的IP地址改ؓ选中的后台服务器IP地址Q然后将数据包发出到后台选定的服务器
3. 后台服务器收到后Q将应答包按照其路由发回到BIGIP
4. BIGIP收到应答包后其中的源地址改回成VIP的地址Q发回客LQ由此就完成了一个标准的服务器负载均衡的程?/p>
在BIGIP上通过讄VIP来截获需要进行负载均衡的量Q这个VIP地址可以是一个独立的L地址和端口的l合Q例如:202.101.112.115:80Q也可以是一个网l地址和端口的l合Q例如:202.101.112.0:80Q,当流量经qBIGIP的时候,凡是命中VIP的流量都被截获q按照规则进行负载均衡?/p>
BIGIP可以定期的通过TCP包对后台服务器的服务端口q行,如果在设定的旉内能收到该服务器端口的回应,则认服务器能提供服务
扩展内容查证(ECV: Extended Content Verification)—ECV
2.3 负蝲均衡和应用交换功?通过各种{略导向到合适的服务?/p>
?strong>动态性能分配QDynamic Ratio-APM):BIG/IP攉到的应用E序和应用服务器的各Ҏ能参数Q动态调整流量分配?br />
?strong>动态服务器补充QDynamic Server Act.):当主服务器群中因故障D数量减少Ӟ动态地备份服务器补充至主服务器群?br />
?strong>服务质量(QoS)Q?/strong>按不同的优先U对数据进行分配?br />
?strong>服务cd(ToS)Q?/strong>按不同的服务cdQ在Type of Field中标识)Ҏ据流q行分配?br />
?strong>规则模式Q?/strong>针对不同的数据流讄导向规则Q用户可自行~辑量分配规则QBIG/IP利用q些规则寚w过的数据流实施导向控制?br />
]]>
随着Browser/Server模式的日渐流行,很多操作都是在浏览器环境下的|页上完成的Qƈ不是只有失效的链接和意外的出错才会操作者感到烦|即便是一ơ完整的成功操作q程Q也可能因ؓ操作的繁复性过高或者用上的不方便而给操作者带来不愉快的体验?/span>
本文试图阐述WEB交互面设计的一些指导性原则,q些原则有利于避免发生不愉快的操作体验。这些原则是用户友好性的Q是在完成同一U操作要求下Q用户最感到L、简单、舒适的WEB交互界面设计原则。我们假定我们讨论的WEB面都是功能正常的,W合学观点的。需要说明我们讨论的原则可能会和设计上的学观点以及既有的功能设计有所冲突。如果发生这U情况,Z“实用的就是美?#8221;观点Q我们会您酌情放弃原先的学观点与功能设计?/span>
1Q?/font> 输入控g的自动聚焦和可用键盘切换输入焦点
使用JavaScript实现面加蝲完成后立卌动聚?/span>(focus)到第一个输入控件。可?/span>TAB键(IE~省实现Q或方向键切换聚焦到下一个输入控件?/span>
输入控g?/span>WEB面表单(<form>)中显式的Q需要用戯行修攏V编辑操作的表单元素。对于这些控Ӟ如果没有自动聚焦操作Q不可避免的出现一ơ用户鼠标定位操作(如果用户此前处于键盘输入操作状态或鼠标定位后需要进行键盘输入操作,实际上是键盘鼠标切换操作Q。如果鼠标定位后需要进行键盘输入操作,如果不能键盘切换输入焦点Q那么不可避免的在切换输入焦Ҏ需要反复的键盘鼠标切换操作Q这是很J琐的?/span>
如果实现了页面加载完成即自动聚焦到第一个输入控Ӟq且可以键盘切换输入焦点标定位操作,那么对于用户来说整个面的输入操作可能都不需要鼠标操作,或次数较,q是一U便利。毕竟频J的键盘鼠标切换操作是比较篏人的?/font>
对于有输入栏的对话框或网,在不q预的情况下应当前控制焦点定位在待输入的输入栏上Q如果输入栏在一般情况下不需要更改其中的内容Q则应直接将焦点定在“定”按钮上;在几个输入栏之间应支?/span>tabQ?/span>shift+tab切换操作Q?#8220;定”?#8220;取消”应该是切换操作的l点Q与具体所在位|无兟?/span>
2Q?/font> 可用EnterQ或CtrlQ?/span>EnterQ键提交Q确保和点击提交按钮的效果是相同?/span>
不要在提交按钮上加入onClick=”…”q样?/span>JavaScript代码?/span>
?/span>Enter键提交页面是原则1的自然g伸,而且q也是浏览器所~省支持的。只所以单独列出来是因为实际上有些设计者设计的面不能辑ֈq种效果Q结果导致?/span>Enter键提交和点击“定”按钮提交带来的效果不一栗大部分情况下是设计者在“定”按钮上加入了onClik=”…”q样的代码,通过点击“定”按钮后,会执行一D?/span>JavaScript代码Q比如对某些hiddencd?/span>input元素讑ր{而?/span>Enter键提交时׃会执行这D代码?/span>
正确的做法是把这D代码移到表单标{?/span><form>中,?/span>onSubmit=”…”属性引入?/span>
对于<textarea>表单元素Q它会消?/span>Enter键,因此会?/span>Enter键提交失效。可以引?/span>JavaScript代码捕捉Ctrl+Enter复合键,一旦捕捉到x行表单的submit()Ҏ。对于需要频J提交的场合Q比?/span>BBS上,q种代码是很有必要的?/span>
3Q?/font> 鼠标动作提示和回?/span>
对用L鼠标定位操作Q当Ud到可响应的位|上Ӟ应给予视觉或听觉的提C?/span>
动作回应的最单Ş式就是鼠?/span>ICON变成手状。浏览器只对hhref属性的HTML标签会自动进行这U变?/span>ICON的行为。对于没?/span>href属性(或没有设|?/span>href属性)的标{,可以通过JavaScript讄style属性的cursor?/span>hand?/span>
目标区域发生变化是更Z动的响应形式。当鼠标指针Ud目标区域Q此时指针图形改变或文字颜色发生改变均能较大的减ȝh索定位目标区域的注意力负担。在按钮上增ȝ观的囑ŞQ尽可能的增大按钮面U;按钮间保持适当的距,太近增加了用户区别它们之间界限以防误操作的负担,太远增加了用h索定位按钮的负担?/font>
4Q尽可能早的在客L完成输入数据合法性验?/span>
输入数据的合法性检验应该在客户端?/span>JavaScriptq行验证。除非验证只能在服务器端完成Q否则验证工作应在最早能完成的情况下q行?/span>
在客L完成数据合法性验证,可以避免一ơ服务器h和回复通讯Q这U通讯是需要用L待的Q如果用L待很长时间后从服务器q回的结果提C出现的错误是在输入时即可发现的Q那么这U设计就是不友好的。诸如密码长度限Ӟ用户名允许字W限制等{,昄应该在客L提交前就应该q行验证?/font>
5Q?/font> Ҏ应用场景军_在表单页面和提交后返回页面间是否使用中间q渡面
Ҏ应用场景Q决定是否显C接收表单页面(表单面和提交后q回面间的中间q渡面Q,以及使用何种方式昄接收表单面?/span>
表单面和接收表单页面是大部?/span>WEB交互操作赖以实现的配合模式。关于表单页面和接收表单面的相互关pȝ设计Q要做如下几个方面的考虑?/span>
一Q对于需要频J操作的场合Q从操作便利和快h出发,可能的减少服务器和客户端交互次敎ͼ应该避免使用中间q渡面。提交完毕直接返回原来的表单面或默认页面。在q种情况下要考虑到数据安全和可恢复性?/font>
如果因ؓ用户输入的数据不合格Q需要重新输入,那么Q去除中间页面,把错误信息直接显C在原表单页面上的设计方式,是最z的处理方式。用户只需要根据错误提C行更正即可。当然这样做E微增加了编E负担。在表单接收面上需要包含原表单面的内容,而且输入数据w必须用服务器端代码或客户?/span>JavaScript讄成用戯入的倹{ؓ了开发快P可以q样做:表单面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下程完成原来两个面的工作:
面脚本初始?/font>
?/font>
?#8220;提交”变量是否讄
?/span>已设|,做数据验?/span>
?span lang=EN-US> ┠验证通过Q?span lang=EN-US>>业务逻辑处理Q?span lang=EN-US>>使用包含面方式或重定向方式q回到特定页?span lang=EN-US>
?span lang=EN-US> ?/span>验证不通过Q?/span>>保存用户输入的数据->退单提交处理到表单面程?/span>
┗未讄Q做表单面程Q如有来自提交流E中产生的用戯入数据,则显C出?span lang=EN-US>
其中Q用包含页面方式返回到特定面可以避免一ơ客L重定向过E,比客L重定向过E还要快捷和E_一些。但是有些情况下因ؓ代码变量冲突或其他原因,使用包含面方式可能q不方便Q这时候可以用服务器端重定向技术,?span lang=EN-US>ASP里是Server.TransferҎQ在Java Servlet里是RequestDispatcher.forward()Ҏ。不要?span lang=EN-US>Response.Redirect或?span lang=EN-US>HttpServletResponse.sendRedirect()q种客户?span lang=EN-US>HTTP重定向方法。不使用中间q渡面也就意味着用户不能后退览原先已经填好的表单页面,因ؓ使用的是同一?span lang=EN-US>URL。所以在验证不通过情况下保存用戯入的数据是必不可少的?span lang=EN-US>
不用中间过渡页面带来的另一个问题就是用包含页面方式或服务器端重定向方式返回会使得URL和页面内容不能一一对应。对于用户可能会直接用这?span lang=EN-US>URLQ会收藏q个URLQ访问返回页面的情况Q他会发现实际上到达的是表单面Q不是他惌的那个返回结果页面。所以,去除中间q渡面Q确实会带来URL和内容含混不清的情况Q因而不适合需?span lang=EN-US>URL和页面内容一一对应的场合?span lang=EN-US>
二,从技术角度考虑Q用中间过渡页面能保证URL和页面内容一一对应Q简化页面开发工作?span lang=EN-US>
Z保证面内容L和固定的URL联系hQ必M用客L重定向:
提交 业务逻辑处理 Q中间过渡页面)
表单面――――->接收表单面――――――――?span lang=EN-US>>昄处理l果――?span lang=EN-US>>客户端重定向到特定页?span lang=EN-US>
客户端重定向分几U情况:1Q?/span>HTTP Header重定向,Location:http://www.netall.com.cnQ这U定向是最快的Q在H口一片空白的情况下就q速访问(GETQ另一个页面。这U方式实际上不能昄处理l果Q只能说是向W一U快速重定向方式的一U折衷处理;2,HTML标签hQ?/span><META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://www.netall.com.cn">Q这U定向比较友好,在这个页面加载完毕后讉K另一个页面。很多设计者把q个作ؓ一个技巧用,在蝲入一个大面前放|一个缓冲页面以避免用户乏味的等待;3Q?/span>JavaScript重定向。由于是用代码控刉定向Q可以做的更灉|。比如根据用户习惯,控制操作完毕后的转向程?/span>4Q被动式的重定向。在面上放|按钮或链接Q由用户手动军_q回到特定页面。这U情况适合于处理结果的昄面包含相当多的信息Q需要用户仔l浏览,而决定下一步的操作?/span>
在用中间过渡页面的情况下,不能再用页面过期失效了。否则一旦出现错误,需要用户重新输入表单数据,用户׃能用后退按钮恢复此前填写的表单数据了。除非设计者有意禁止这U恢复?/span>
6Q?/font> 防止表单重复提交处理
Ҏ交按钮点d做变灰处理避免在|络响应较慢情况下用户重复提交同一个表单。用页面过期失效避免用户后退览重复提交表单?/span>
有些复杂的应用会D需要较长时间的{待才会q回处理l果。而在较慢的网l环境中Q这U情冉|是频J发生。焦急等待的用户往往会重复点L交按钮。这U情冉|设计者所不希望看到的?/font>
使用JavaScript在点L交按钮后使按钮失效变灰是一个最直接的办法(Ҏ原则2q段代码应该攑֜<form>标签?/span>onSubmit=”…”做)。此外,在表单页面上Q用服务器端脚本讄HTTP Header?/span>Expires为立卌期可以保证用h办法使用后退览恢复表单面。注意这样做的代价可能是用户辛辛苦苦填写很长的内容,l果一旦操作失误就没法恢复。所以应该避免在包含<textarea>表单元素的页面上使用面q期失效?/span>
应该_更严格的Ҏ是,服务器端脚本应该具备抵抗重复提交的能力。例如,个表单分配一个唯一ID或一个用一ơ即失效的验证码。此外,q个表单处理q应h事务性质Q如果表单不被接受,所做的改变q是能恢复的。在金融应用场合Q重复提交同一W交易是肯定不被允许的。能在重复提交中获利的一ҎL会想办法l过览器的限制Q所以不能依赖于客户端的技术?/span>
7Q?/font> 面链接是打开新窗口、用原H口q是弹出H口的原?/span>
一般而言Q首上链接可以使用target=”_blank”属性打开新窗口,而其他页面上的链接都应用原H口或弹出窗口。如果链接页面内容相对原面来说不重要,是附属性质的,可以使用弹出H口方式?/span>
一般情况下应该使用原窗口,把是否保留原H口内容的权利留l用戗除非设计者相信原面是如此重要,在用户发出点L令后q有使用上的价|以至于不能被随便更新或覆盖。一般来_只有首页才会处于q样一个地位,用户在首上打开一个链接后Q一般还会在q个首页上去打开另一个链接。比如首包含极多链接的门户|站Q或者搜索引擎的搜烦l果面?/span>Google.com以前的搜索结果页面上的链接是使用原窗口的Q后来他们意识到用户会反复用这个页面,而改成打开新窗口了。一般的|站如果首页链接不多Q就不必使用新窗口,q是用户友好的设计原则?/span>
上述情Ş的一个极端情况就是新面内容比v原页面内容的重要性差很多Q以至于都未必需要打开一个新面。这时候用弹出窗口比较合适。用JavaScript弹出H口有好几种Q一个是window.open()函数。这里有个技巧。应该?/span>window.open()先打开一个空白窗口,再?/span>location.replace()用目标页面替换。这样做可以避免在打开新页面的q程中导致原面失去响应?/span>Window.open()打开一个新的浏览器H口q程Q因此资源消耗比较大。另一个是由微?/span>DynamicHTML规范中扩充的ҎcreatePopup()?/span>createPopup()可以创徏无边框的弹出H口Q消耗系l资源较。还有一个就是用面中隐藏的?span lang=EN-US><div>来模拟一个弹出页面。后两种可以使用JavaScript代码填充弹出H口内容。如果需要下载网作为其内容的话Q需要微?/span>DynamicHTML规范中的<download>标签?/span>
8Q?/font> 可能少的排列可选项Q尽可能的安排操作步骤
Ҏ用户操作习惯安排可能少的操作菜单选项Q同时要保证可能少的操作步骤?/span>
在不降低功能多样性的前提下减菜单项和操作步骤是用户友好的设计。要做到q一点很不容易。要从用户出发考虑他们最频繁的操作是什么。正常情况下一个用户需要的操作d以归cMؓ5个以下的U类Q如果出现更多的U类Q那一定是没有针对用户兴趣d分主ơ。一个用户同时有5个以上的强烈兴趣中心是难以想像的Q走马观׃的随意点L览的用户Q是不大可能在某个种cMq行深入的交互操作的。在q?/span>5个种cMQ每个种c都可能有若q个可操作的二U类。如果这些二U操作项是不可见的,那么意味着要做两次选择才能q入可操作页面。这p背了“可能少的安排操作步?#8221;q一原则。如果?/span>JavaScript制作二菜单Q避免请求服务器Q会好一些。如果二U菜单项d不超q?/span>20个左叻I不妨二U菜单直接显C出来,比如攑֜左列一字向下排开Q这样只需要一ơ选择到可操作,更加明了方便?/span>
9Q?/font> 操作逻辑无漏z,保证数据是操作安全的
多个面间的操作和同个页面上的多个操作间的逻辑关系在设计上是安全和严}的。保证不会出C被允许的用户操作l合Q至不会因为用L不适当的操作导致出错?/span>
q最典型的表现则是在面上广泛采用的所谓联动下拉框设计。一个下拉框中允许的选项受另一个下拉框中的选择而变。另外一个例子是Ҏ选择使表单元素有效或者失效。如果在多个面间也要维持某U合法性逻辑Q那么就需要服务器端脚本的参与。这样会使表单设计跟操作有关Q应该说q不是一个好的设计。可以通过变更操作步骤序、组合方式来可能避免这U情况出现?/font>
操作逻辑的设计既要保证用户Q意的输入不会D错误Q也要保证是用户输入的数据能购被安全处理。在Session控制下的表单中输入大q文字可能会D时出错Q这时候往往q伴随重定向q程Q导致用L长篇输入荡然无存。用JavaScript提醒用户已超Ӟ请保存输入后重新提交Q是一个好办法。某些表单元素如<input type=”text”>接受ESC键清除数据,q且无法撤销Q这也是很危险的。在中文输入法中常常使用ESC键清楚输入的码位Q一旦不心多按一?/span>ESC׃使得输入数据消失。因此有必要?/span>JavaScript用<input>?/span><textarea>?/span>ESC键处理过E?/span>
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=413028
板桥里h http://www.jdon.com 2005/04/28
以数据库为核心的软g时代已经q去Q数据库时代早已l束Q当我看到J2EE征途中那么多h在对象和数据库之间彷徨痛苦ing的时候,我想我该出来喊一C?/p>
其实q句话在几年前肯定有人喊q,因ؓ中间件时代的来Q实际意味着数据库时代终l,正所谓一山无二虎Q如果你重视数据库,你的J2EEpȝ无法完全OOQ只有你忽视数据库,你的pȝ才有可能完全q向OOQ至于数据库性能调优{特定功能都可交由EJB容器或O/R Mapping工具实现?
很多q前Q包括我自己在内的大部分企业E序员都是从数据库开始我们的职业生Q最早的是dBase/FoxProQ后来有?SQLpd数据? Oracle数据库时代推向了顶峰?/p>
每当有一个新目ӞW一步就是首先设计出数据表结?Table Schema)Q然后开始用SQL语句实现业务逻辑Q这U开发模式一直重复,是后来加入了DelPhI/VBQ他们也只是承担囑Ş昄实现Q这UC/Sl构带来最大问题是Q非帔R于维护,修改hQ迁一动百?/p>
软g的生命在于运动,当它需要发展时Q最的软g人员如果对他也束手无{,q是谁的悲哀Q?/p>
现在更多人开始接受B/Sl构Q但是他们中很多没有真正明白Z么需要B/Sl构QB/S代表的多层架构才是真正目的(因此Q伪多层的B/Spȝ遍地皆是Q?/p>
多层架构实际是将以前pȝ中的昄功能、业务运功能和数据库功能完全分开Q杜l彼此的耦合与媄响,从而实现松耦合和良好的可维护性?/p>
一. 从设计上_׃实现层次完全分离Q业务运功能成ZU中间功能(中间层)Q它不依赖具体的表现层技?Jsp/Html applet{?Q也不依赖具体数据库技术(Oracle/SQL ServerQ,业务q算功能q行在J2EE应用服务器中Q当我们的业务运功能不再依赖数据库Ӟ是否意味着数据库已l不是重点?
? 当然Q多层结构带来了性能问题Q客L讉K数据库中的数据时Q通常需要经q多个层ơ,非常耗费性能Q?如何量减少数据库访问是J2EE应用pȝ首要解决的问题,使用存储q程q没有解册个问题,存储q程的执行还是属于后端,q没有羃短客Lh所要经历的坎坷路途?/p>
解决性能问题的根本解决之道是使用对象~存Q现在, 64位CPU提供的巨大内存空间ؓ单台~存计算提供了硬件基Q更重要的是Q这U缓存计是可~的Q通过集群的缓存机Ӟ如JBossCacheQ, 通过增加应用服务器的数量Q可以提高整个业务逻辑层的~存计算能力Q抛弃过去那Uؓ内存斤斤计较的老思维吧?/p>
? 在系l分析之初是否首先需要数据表设计呢?回答是否定的Q?以UMLZ表面向对象的分析设计Ҏ已经成ؓ强大工具Q随着面向模型驱动分析设计QMDAQ的普及Q?面向数据库分析方法正在逐步被抛弃,拥有深厚传统数据库分析习惯的E序员必面对和接受q种挑战?/p>
U观整个J2EEpȝ开发过E,数据库已l从q去的中心位|降ZU纯技术实玎ͼ数据库只是状态持久化的一U手D(文g是另外一U实现手D)Q什么是持久化?q是相对于内存缓存状态而言Q持久化是当内存断甉|况下能永久保存状态数据,但是如果J2EE应用服务器是7X24时集群q行Q几乎永不当机,是否有持久化的必要呢Q?/p>
很显Ӟ数据库已lZ操作pȝ中文件系l同L层面Q以它ؓ中心的时代真的结束了QIBM早期DB2数据库开源已l强烈向我们昭示q点?/p>
对于J2EE初学者来_早抛弃q去的两U媄响:q程语言~程习惯和以数据库ؓ中心的设计习惯,从全新的面向对象角度(OOA、OOD和OOP、AOP)来设计开发你的J2EEpȝQJ2EE设计开发三件宝Q?a target="_blank">Model、Patterns和Framework?/p>
以上不只是理论,而是我每天正在做的,如果你也是或赞同请广Z播,唤醒更多彷L痛苦的初学者?br />
TSS最q相x章:
DDD(Domain-Driven Design领域驱动设计)实战