GWT初探

之前在Vanessa的Blog中知道有GWT，初看了一下功能，确实蛮符合我的口味的，并答应要研究一下。前几天公司项目的一个规格要写，挺赶时间的，没来的及，今天周末上来，就看了一下。还是有点收获的，至少知道啥是GWT了。 google搜索引擎查出来的资料很多，糟粕和重复的文章也不少，我整理和过滤了一下，剩下的绝对是精华了，大家有兴趣的可以直接访问：http://www.1000100hui.com/Control.html?PageIndex=28&PageTypes=51 记载的文章很多，重复内容的我就不多说了，只说一下我的感受。 GWT我直接感受就是把javascript转换成java来开发的框架。而关于页面的开发，我发现至少（java方面是这样的）已经有非常非常多的架构了。包括JSP(这个是最土的)VM、JFS、EXT、Struct等等。为何出现那么多这种技术呢？我想原因一定是原来的架构会存在一定缺陷。是的，原来的结构中，java和页面，就是两个领域的东西，一个关注于逻辑，一个关注于展现。但是面对程序员，要处理这截然不同的两门技术，那就困难了。所以，后面为提高效率，出现了很多这种页面框架，用以提高页面工程的开发效率。但至今没有一个是完美的（要不然不会层出不穷发现很多新花样）。 我觉得，这里最困难的地方就是“混合体的问题”，同一个功能逻辑下来，要经过两个完全不同的技能方向的人员进行开发。确实是很痛苦。而反观，这些框架，JSP、VM等模板类型的处理方式，不但没有解决问题，反而将问题更复杂话。把逻辑代码和页面代码弄的更加血肉模糊。大家可能有经验，反正我是对jsp深恶痛绝。原因是这个东西根本无法作有效单元测试，只能通过把环境搭建起来后，慢慢的在页面上跑。效率及其的低下！ 这个问题的解决，有两个方向，一个是彻底隔离。页面就去请美工做，逻辑请程序员做。把双方之间的接口定好，各自测试各自的，谁都不影响谁。我比较喜欢这种方式，不过这个不是今天讨论的问题。另外一种方向就是，把其中一个东西变成另外一个东西来处理。 我想GWT用的就是第二种方式来解决这个问题的。将页面工程转换成java，最后用工具转换生成出javascript和html！所以，大家看GWT的时候，会觉得，哇这个简直就是java的UI编程，一摸一样嘛！ 由这种模式带来的好处我就不说了，外面的文章凡是提到GWT的，都会说明1、2、3、4、5点等等。。。。。。 我想说的是几个GWT的问题，不，应该是说我的疑问吧。 1。GWT在开发上确实能提高效率吗？简单的说从代码量的角度上讲，它仅仅是把几个常用的JS代码转换封装了一下。但是我个人觉得从语言表达的能力来说，java和javascript应该是一个级别的。应该不会存在一个比另外一个高效多少的问题。准确来讲，javascript更灵活，但java更严紧。两者在全流程开发上面（SRS、Design、Coding、Testing）两点差别基本上相互补平了。 2。页面丰富性，我始终觉得java的Swing开发模式不会比html优秀。而且针对现在层出不穷的页面开发工具，就不要从效率上说明了，就是从效果上讲，差别就不是一个数量级的了。当然GWT有它的办法可以泥补这点，因为GWT设计确实灵活，它甚至可以只对页面的一个小部分如，某个Div里面做一个模块进行设计。我看的东西还不多，以上是我的一些思考的观点，注意，并不是我反对GWT。我说过了，GWT的优点到处都有，不用我再罗嗦了而已。这是来自IBM上的文章节选：在代码生成的情形中 GWT 架构中最具争议的问题可能就是在客户端代码中对 Java 语言的切换。有些 GWT 的拥护者认为用 Java 语言编写客户端代码实际上要比编写 JavaScript 好。并不是所有人都赞成这个观点，许多 JavaScript 程序员极不情愿牺牲他们语言的灵活性和表现力，来获得有时非常繁重的 Java 开发工作。用 Java 代码代替 JavaScript 比较有吸引力的一种情况就是：团队缺少有经验的 Web 开发人员。但是，如果团队正在转向 Ajax 开发，那么最好是雇佣有经验的 JavaScript 程序员，而不要依靠 Java 程序员利用私有的工具生成混乱的 JavaScript。由于 GWT 扩展到 JavaScript、HTTP 和 HTML 的漏洞所导致的 bug 是不可避免的，所以缺乏经验的 Web 程序员要花很长时间跟踪它们。作为开发人员和博客，Dimitri Glazkov 指出：“如果不能处理 JavaScript，就不应当编写 Web 应用程序的代码。HTML、CSS 和 JavaScript 是这条路上的三个必备条件。”（请参阅 参考资料）。 有些人认为因为有了静态类型化和编译时检测，Java 编码天生就比 JavaScript 编程不容易出错。这是一个相当靠不住的论调。用任何语言都可能编写糟糕的代码，大量充满 bug 的 Java 应用程序就是证明。也可以依靠 GWT 的代码生成来消除 bug。但是，离线语法检测和客户端代码的验证无疑会带来一些好处。JavaScript 也可以用 Douglas Crockford 的 JSLint 的形式得到它（请参阅 参考资料）。GWT 在单元测试上有优势，可以为客户端代码提供 JUnit 集成。单元测试支持仍然是 JavaScript 很欠缺的一个领域。 在开发 Weather Reporter 应用程序时，我发现客户端 Java 代码最引人注目的情况是它在两个层上共享一些验证类的能力。这显然减少了开发劳动。跨 RPC 传递的任何类都适用这种情况；只需要编码一次，就可以将它们用在客户机和服务器代码中。不幸的是，抽象是有漏洞的：例如，在我的 ZIP 代码验证器中，本想使用正则表达式执行检测。但是，GWT 没有实现 String.match() 方法。而且即使它实现了这个方法，在将 GWT 中的正则表达式部署到客户机和服务器代码时，也存在语义上的差异。这是因为 GWT 对宿主环境底层的正则表达式机制的依赖也是不完美抽象所带来问题的一个例子。 GWT 非常被看好的一个重要原因是它的 RPC 机制和内置在 Java 代码和 JavaScript 之间的对象序列化。这消除了普通 Ajax 应用程序中可以看到的许多繁重工作。但是，它是有前提的。如果想使用这个功能而不使用 GWT 的其他部分，那么 Direct Web Remoting（DWR，它用 Java 代码和 JavaScript 之间的对象伪装提供了 RPC 功能）非常值得考虑（请参阅 参考资料）。 对于将 Ajax 应用程序开发的一些低层方面（如跨浏览器的不兼容、DOM 事件模型和进行 Ajax 调用）抽象出来，GWT 做得很好。但是现代的 JavaScript 工具包（例如 Yahoo! UI 库、Dojo 和 MochiKit）都提供了类似级别的抽象，却不需要求助于代码生成。此外，所有这些工具包都是开源的，所以可以对其进行定制，以满足自己的需求，或者在出现 bug 的时候进行修补。对于黑盒子式的 GWT，这是不可能的。（请参阅 许可 侧栏）。 回页首 结束语 GWT 是一个全面的框架，提供了许多有用的功能。但是，GWT 并不是万能的，它针对的只是 Web 应用程序开发市场中一个相对狭窄的市场。我希望这份简要的介绍能让您对 GWT 的功能和局限性有一定的了解。虽然 GWT 肯定不会满足每个人的需求，但它仍然是一个主要的技术成果，在设计下一个 Ajax 应用程序时，值得认真地考虑 GWT。与我在这里介绍的相比，GWT 具有更广的广度和更深的深度，所以请阅读 Google 的文档，以了解更多内容，或者加入 GWT 开发人员论坛上的讨论（请参阅 参考资料）。

这只是第一印象，后面还要继续深入和挖掘，努力........

版权声明：本文为博主原创文章，未经博主允许不得转载。