jQuery Ajax 和 Struts2 渲染机制对比. 性能取舍

最新推荐文章于 2024-09-18 23:27:31 发布

ckstory

最新推荐文章于 2024-09-18 23:27:31 发布

阅读量2.5k

点赞数

文章标签： struts ajax jquery velocity 服务器 html

本来 ajax 与 struts2 并没有什么冲突，但在页面的渲染方面，作为开发者来说，还是有的选择的。下面各来看一下它们的工作情况：

1． Ajax 方面，由于大量的开发包，使得浏览器端的 DOM 变化莫测，并没有什么一定之规。

（1） 用 Ajax 对数据进行渲染。

由 DWR 之类，或 servlet 或 struts2 的 JSON 插件，向浏览器端提供数据的 JSON ，以纯数据形式交互，再由 Ajax 在页面对 JSON 进行渲染。现在的开发包， EXT 等都有绑定 JSON 的功能，渲染形式可以任意调整，可以说达到页面级的 MVC 的最高境界。缺点可能是，由于发展太快，开发人员对这些开发包的了解还是有限的，而且各个开发包的书写风格并不统一，也是由于 javascript 的书写风格可以很个性决定的，一方面，你可以尽量展开想像，另一方面，写得精采的代码不是那么易于理解。

（2） 用 Ajax 对 HTML 元素进行渲染

Ajax 开发包也提供这样的功能，以 HTML 元素作为最小的单位进行渲染，如：加入动作、加入 style 等。页面可以变得很干净并易于理解：

<table><tr><td>…….</td></tr></table> 而，如隔行变色的渲染，完全无需写入 HTML 代码，

$$('#result li:nth-child(2n)').invoke('addClassName', 'alternate'); （《 Prototype and script.aculo.us 》）以 prototype 来说，这样就可以了。当然，也可以由（ 1 ）的方法，先生成 HTML 代码，第二步再进行渲染，这个问题后面再说。

（3） 用 Ajax 进行布局

这也是一个比较有意思的功能，利有 Ajax 的异步请求功能，将大块的 HTML 代码以 CSS+DIV 的控制方式放到页面的不责骂位置，而达到布局的目的。有点像 portallet 的方式，好处是进行单块刷新时，既无需全页面刷新，也无需以 FRAME 方式处理页面。再加上“拖拽”功能的实现，可以很方便地达到个性化页面效果。

2 ． STRUTS2 方面，加入了很多 TAG 标记，再结合 sitemesh ，利用 velocity 或 freemark 的模板功能来实现页面在服务器端的整合。

（ 1 ） struts2 标记以 component 方式出现

Struts2 以传入的 entitybean （ POJO 对像）为基础，对数据（实际上是对这个对像）进行渲染，对于 FORM 、 CHECKBOX 等有比较成熟的用例。而且甚至也有一部分开始结合 script 来做，比如 validator 的使用，结果倒是在头部加了 JS 来完成信息的反馈。在实现方面， struts2 还是比较开放的，允许 jsp/velocity/freemark 的方式来实现 tag ，而且还可以自定义开发，在使用 component 标记时，可以任意开发。但总觉得还是有些限制在里头，回头想想，“自由是在有条件下的自由”，这样未必不好，标准化的开发对于软件工程和效益角度来讲，都是有利的。

（ 2 ） struts2 以 sitmesh 方式布局渲染页面

作为一个 struts2 的“装饰”拦截器出现的 sitmesh ，实际可能倒像是在 struts2 的外面，可解析返回的 HTML 流，重新进行“装饰”。好处是有点“无侵入”的意思，和 component 结合使用的话，确实只是装饰的作用，并不要求对业务部分进行多大的变化。可重用性提高了不少，比高耦合的 include 的方式要好得多，而且也支持 velocity 和 freemark 的模板功能。其实模板功能 velocity 已经完成得不错了， sitmesh 只是采取了结合类似“路由”和拦截器的用法，标准化了一些。

3.Ajax 方式与 sturts2 的方式结合

正所谓此消彼长，都想干这活儿，得看应用的环境和意图来取长补短。 Ajax 的长处在我看来有两点，一是比较“绚”，页面的交互人性化，另一点是页面的 MVC ，使得页面与服务器之间的数据交流效率最高。缺点也不少，就开发而言，浏览器差异是最难面对的一个问题，当然，有三方开发包在，可以以面板或代理模式解决大部分问题，但开发包本身也不一定是规范的，或者说不是标准的。这样就有一个问题，开发者需要学习如何使用开发包，而现在真正对页面 MVC 了解的开发人员，不是很多，成本效率都有点问题。 Struts2 的长处，其实是其标准性，从 JSP 的角度来讲，开发成本和效率以及人员选择都好一些，二次开发或修改的时候，比较容易理解。而从 IDE 角度来说，更是有先天的方便。“虽然僵硬，但比较简单”。缺点是交互性差，或者说比较简单，如果自制的成本过高的话，重用和变化就比较难。而且一些工具看似方便，其实是可有可无的，因为可能由其它应用服务器以外的工具来完成更好。如： sitmesh 的路由功能，如果是集群工作，由 apache 或其它的 WEB 服务器来完成性能好一些。（这里其实是有故事的，暂不提了，但谁也不相信可以由单个 tomcat 来面对公网的高并发访问）。再就是渲染的灵活性，如：写一个 <td class=<%.... 来隔行换色，比起 ajax 的“ ….nth-child(2n)').invoke('addClassName….' 来，逊色不少，耦合性也高了些。

所以，如果从性能本身来讲，在渲染页面这个问题上， Ajax 自是高 struts2 一层 ; 但从项目开发效率和成本角度看， struts2 似乎更易被接受（不要高估开发人员对新事物的接受能力） ; 从长远的复用性和开发平台角度看， Ajax 是早晚的趋势，只是要注意，不要跑到趋势的前头，趋势不代表主流，从现实角度看，完全的 Ajax 渲染存在很多问题，即使可用，维护上也成问题，即使可维护，更新的速度过快，很大程度上降低了稳定性。关键是没有标准，你可以以 EXT 或 mootools 或 DOJO 为基础标准，但谁又知道它们以后发展的情况，会不会停止更新，会不会收费，就连文档方面也是很少的。而 struts2 呢，从 struts1 的过渡似乎正在进行中，有人说至少 1-2 年内还是 S2S2H3 当道，我看也是可行的。从长远的角度考虑，技术的先进性并不占多大比重，开发人员的熟练度和开发平台（包括测试）的成熟度要更重要一些。真正的可重用性，还是要以项目的情况来决定的，相当于有一个投资的回报期和利润平衡点，要达到一定的量才有建立开发平台和固定架构或是解决方案的可能。从真正使用角度来看， struts2 基本具备升级的条件，特别是它开发的架构，使开发人员有更多选择的余地，使建立平台的成本随着时间的流逝，仍可以保留一些价值，不至于一次性推倒重来。另外，还有一个渲染粒度的问题，从哪一个层面进行，开发人员的分工能否够细，接口是否清晰，都是间接的选择条件。但并不是说 Ajax 用不上，如果不及早地介入 Ajax 的历程，在真的技术升级换代时，会比较困难的，何况 Ajax 也并不那么难，甚至可以说很简单。它也提供开发人员不同的选择余地，你既可以对 JSON 或 XML 数据进行渲染，也可以对已有的 HTML 元素进行渲染，至少也能够根据 CSS+DIV 对页面进行布局。

4 ．最佳实践

我不知道怎样才算是最合适的，就业界的整体情况而言，我不得不说，还是要适度的使用 Ajax 。那些以纯 script 为基础的整系统框架 framework ，在我看来都不是那么的完备和稳定。 RIA 从某个侧面确实减少了 C/S 的那种更新发布的痛苦，也在表现层面上给予了尽量多的支持，但从安全等层面上来说，还是有欠缺的，在一个特定的环境下使用还是有利的。

选择组合的环境大约有两种：一种是公网下、高并发、页面交互复杂、页面表现要求较高的情况 ; 另一种是 B/S 结构下、类 MIS 内网应用系统、页面要求标准、有利于二次开发或扩展或第三方产品介入等要求、业务流程 / 数据结构复杂但表现规律的情况。

对于环境一，显然要求与服务器交互数据越少越好，而且大部都会形成静态页，所以动态效果不能做到服务器端（虽然方便或者可以集群，但这仍是主要设计原则之一），只能做到浏览器端，也就是“静态页面中的动态效果”。当然 Ajax 是首选，从项目团队角度来讲，只要人员素质能达到，越细粒度的渲染越好（有点过于夸大了，普遍地说吧），甚至服务器端的应用开发都可以以不同方式开发 ( 可以用 java 也可以用 PHP 也可以用 .net) 。现有的架构中， DWR 可能用的最极至的，而且也对原来用 java 的开发者转到 javascript 是一个比较容易的过度（虽然没真用它开发过，但想来是如此的）。 Struts2 的 JSON 插件或其它三方产品也可以，只不过业务逻辑放到服务器端而不是浏览器端，个人认为还是这样比较好，将表现逻辑和业务逻辑从物理上就分开， EXT 等框架已经比较支持这种方式了。当然，如果达不到素质，仍可以在局部使用 Ajax 的效果，如无刷新更新页面、拖拽等。

对于环境二，团队开发的情形更多一些，一些以 struts2 为基础的自制开发平台是团队的首选。无论是对平台的开发，还是应用平台的二次开发，标准化和复用是项目获利的关键。所以，依我之见，宁可死板和重复一些，不要过份要求代码的完美（但逻辑要清晰，数据结构要好， SQL 要效率高）。 Ajax 的使用要比较局部，一些开源如 GT-Grid （原来是基于自定义标签的，现在好像基于 sript 渲染 JSON 了）等，在表单增删改查的这个局部做的相当不错，在 ss2 中可见一斑（ ss3 中还未见例子），借助 struts2 的开放性，并不需要在所有地方都使用，一些地方仍可沿用原来的服务器组装页面的模式（ sitmesh ）。但这个我没有也不好比较，是 Ajax 来还是由 sitmesh 进行页面大布局中各个子部分内容的载入，因为本来以为用 Ajax 的异步请求载入子部分内容的用户体验是最好的，但使用 Ajax 的建议中倒认为应尽量减少请求数量（但这里好像指高并发的情况下），而且如何载入，需要自己写代码（我是写成 XML ，再由 script 读入后找到各部人的 URL 再载入的）。而 sitmesh 也是写配置文件，代码都缩到 jar 里面，再结合 struts2 ，代码量比较小，感觉也比较可靠和灵活。也就是说，一个是将布局定义放到浏览器端执行，一个是将布局定义在服务器端执行。相比之下，如果要改模板，还是 sitmesh 好一些，如果要拖拽和个性化，还是 Ajax 效果更好。其它的普通页面，我认为以 struts2 的标签为基础，生成一些标准 HTML 元素，再以 Ajax 渲染 HTML 元素的方式是比较好的选择，而 Ajax 的渲染部分可以放到头部，由 sitmesh 配置，小的也可以放到自定义的标签代码中，这样页面代码（模块）比较标准和统一，要变化页面组合或渲染方式时只在配置上做文章。另外，纯以 struts2 的标准标签进行渲染，我并不赞成，除非是有非常固定的页面，又没有开发新样式的成本，否则页面太 DEMO 了，不具有实用性。

总之， Ajax 和 struts2 各都有开放的特性，可以以不同粒度渲染页面，依据环境的不同，比较平衡的组合，依据开发人员层次，细分对数据逻辑的渲染和对表现逻辑的渲染，举个例子：用土做砖，用砖盖房，细化为不同流程，如果说用土盖房，将做砖的业务合到盖房的业务中，看起来是有问题的。专业一些的比方：我们为提高开发效率把美工和应用开发分开。以松耦合高内聚为前提的细化分工，是提高效率的基础。

原文链接: http://shishi11.iteye.com/blog/281434