真实世界的 ZK 与 GWT 体验

Posted 2023-02-23

【中文标题】真实世界的 ZK 与 GWT 体验

【英文标题】：Real-world ZK vs GWT experience

【发布时间】：2011-03-30 05:35:06

【问题描述】：

我和一位开发人员正在为一个新的应用程序提出一个提案，我们已经提出了 ZK 和 GWT 作为可能的选择。在搞砸了两者之后，我更愿意继续使用 ZK 概念验证，但是公司的一位“高级架构师”（甚至不在我们团队中）似乎正试图接管该项目并告诉我们要采用哪些技术。他正在寻找任何借口将 GWT 推到我们身上并对 ZK 犯规。

现在我并不是说 GWT 天生就不好，也不是说 ZK 是万维网应用程序开发的万能药，但我不喜欢有人告诉我如何开发应用程序还没有真正做足够的研究来推动一项特定的技术。虽然这个人不在我们的团队中，但管理层倾向于听取他的意见，并且可能会“告诉”我们使用什么。

这家伙反对ZK的论据似乎是“浏览器不兼容”、“浏览器业务逻辑过多”、“项目不成熟”。这三个我都不同意。他也没有为 GWT 提供任何论据，这似乎他实际上对这两种技术都不太了解。他还声称最好使用公司内部有人知道的技术。这里只有一个团队实际使用过 GWT，而且那个项目有……问题。

在 ZK 和/或 GWT 方面有一些实际经验的人能否提出一些我可以提供的论点，以至少将这两种技术重新放在桌面上，而不是试图在没有真正研究的情况下推动单一技术？

【问题讨论】：

作为文章 GWT vs. ZK 的作者，我想说我并不喜欢一种解决方案。

【参考方案1】：

ZK 更易于使用，并且在 API 方面具有较低的学习曲线。另一方面，如果您想创建所有排列并且您不使用适当的插件进行即时编译，则 GWT 更难学习且体积更大，因为它可能需要很长时间才能编译。后者提供了更快的用户体验。如果您想快速为 Intranet 应用程序创建 GUI，请使用 ZK。如果您面向更多的受众，请改用 GWT（GWT 中缺少标准组件并不是一个真正的因素，因为您可以改用 GWT-ext，另一方面，最重要的 ZK 组件是专有的）。

【参考方案2】：

也许展示一个成功的企业级 ZK 应用程序会有所帮助。

当我第一次使用 IDempiere 2（ERP+CRM 软件）时，我的思绪被震撼了。这是一个巨大的 ERP 软件，具有非常灵敏和干净的界面。

不到一个小时，我就将它安装在了一台 Windows 机器上。

【参考方案3】：

GWT 和 ZK 都提供了在 Java 中启用 Ajax 的框架。两者都很成熟，没有浏览器不兼容问题（ZK基于jQuery）。

但是，它们在架构上非常不同。 GWT 是客户端方法——所有代码在客户端运行，而 ZK 服务器端方法——所有代码在服务器上运行（但他们可以选择在客户端编写一些应用程序代码）。所以，你的同事错了，你已经知道了——GWT 将业务逻辑暴露在客户端，而不是 ZK。

GWT（作为客户端方法）的优势是响应速度更快（如果设计得当，客户端-服务器请求更少）。缺点是您必须在客户端和服务器之间进行所有数据封送处理（GWT RPC/JSON 仅支持非常简单的对象）。相比之下，ZK 的优势是你可以直接访问所有后端资源，没有 RPC，没有代理......另外，ZK 允许你在客户端编写一些代码来增强关键部分的响应能力（不幸的是，客户端代码必须是 javascript）。对我来说，这是最好的平衡。

GWT 的真正优势在于 Google。我不断听到一些老板因此将工程师推向 GWT。我还听说一些 GWT 项目失败了（主要是由于生产力问题——如果项目复杂的话太痛苦了），然后切换到 ZK。

【讨论】：

谢谢，我会带上它的。

使用 ZK，您可以将自定义逻辑保存在服务器上。框架动态地将其作为 js 数据通过 ajax 发送到浏览器。 ZK 有大量的 js，但你通常不会直接使用它。它在 jar 文件中，zk servlet 将其发送到浏览器。优点是所有框架 js 代码都经过其他人的良好测试。如果您编写自定义 js 代码，您必须自己在许多浏览器的许多版本中进行测试。 zk5 有一个 javascript api 可以让您更轻松地自定义 javascript，但最好避免这样做，因为跨浏览器 js 很难，这就是 GWT 很难的原因。

说到跨浏览器兼容性，GWT并不比ZK的JS代码好。 ZK 基于 jQuery，它的小部件会处理他们知道的问题。 GWT 仅解决 Java 到 JavaScript 的转换，但 JavaScript 本身没有跨浏览器问题。 DOM 的访问是问题所在。如果您使用 GWT 访问 DOM 或带有 CSS 的样式，那么您可能会遇到 GWT 无能为力的情况。

【参考方案4】：

我从未使用过 ZK，但从外观上看，ZK 更“适合企业”，因为它带有许多即用型小部件。 GWT 最近才获得了一个类似 DataGrid 的控件。在 GWT 中重新创建 ZK 的日历或电子表格需要大量的工作。

你是老板的“浏览器中业务逻辑过多”的说法确实表明他并不真正知道他在说什么。 GWT 是一种仅限客户端的技术，而 ZK 看起来几乎完全是服务器端的。

如果您还没有查看ZK's GWT vs. ZK page。他们似乎覆盖了大部分基地。

最后，请记住，你是编写程序的人而不是他，如果老板强迫你做一些需要更多时间来实施的事情，然后相应地夸大你的估计。用他们关心的东西来吸引管理层要容易得多：“这项技术将使预算增加 X 并按 Y 计划”，然后是技术细节。

【讨论】：

嗯...他可能已经看过那个页面，但如果没有，我会把它传给他。我不敢相信我没有找到开始。如果管理层决定他们宁愿听他而不是实际的开发人员，那么预算/进度的争论似乎是一个很好的选择。谢谢你。

@Samah：遇到了你的问题。我很好奇，你最后做了什么？过去我曾与 GWT (+GXT) 合作过，我很喜欢它。现在，我开始关注 ZK。这似乎很有趣。帖子中包含的文章只是营销 bs。它并没有真正深入。毫不奇怪。

@costa：我们最终选择了 Zk。我们仍然需要做很多后端工作才能让它与我们现有的传输方法进行交互，但最终我认为这是正确的决定。如果我们采用 GWT 解决方案（或其他类似的解决方案），将会有更多的客户端/服务器交互来开发我们自己，而且我们的时间紧迫。

【参考方案5】：

公司董事讨厌风险和不确定性。如果有很多开发人员说一个框架很酷，而一个架构师却咬牙切齿地抱怨风险，那么他们就会一次又一次地接受反对者。您需要获得软件的第三方独立参考，即使使用开源也是可能的。

至少有一家公司出售 ZK 支持。他们很乐意让您与使用 ZK 的公司的架构师取得联系。向这些独立的第三方架构师提出一组开放式问题，例如“你最喜欢什么，最不喜欢什么”和“你发现的主要挑战是什么”和“最让你惊讶的是什么”和“其他框架做了什么”你考虑过，为什么选择ZK”。公司董事喜欢这种基于事实的研究与其他公司的高级人员交谈。

同时设计一个“突击课程页面”，它公平地代表了您必须在项目上构建的那种复杂性。让团队在 ZK 和 GWT 中实现该页面，并让每个人都尝试改进两者。把这段经历写成一个团队。一定要包括反对 ZK 的人，不要以对抗的方式这样做。不要陷入他们与我们或她与我的情况，而是将其作为一个开放的团队事实调查和培训练习，任何人都可以做出任何贡献。 Wiki 页面可能是一种理想的格式。

您将通过这种方法获得成功，因为 ZK 已被用于价值数百万美元的开发项目，团队中有超过 30 名开发人员在价值数十亿美元的全球金融公司。您是喜欢使用 ZK 的好公司之一。

【参考方案6】：

请注意，ZK's GWT vs. ZK page 页面由 Potix Corporation 的工程师 Jeff Liu 撰写。 ZK是哪家公司生产的。

我也在努力在 ZK 和 GWT 之间做出选择。我正在寻找最近的一篇公正的文章，它讨论了这两者，但找不到任何好的东西。

【讨论】：

自己编写 :-) 选择一个页面，例如 google 搜索“mvc zk jpa spring”显示的简单应用程序，并将该页面的 gwt 版本添加到该示例代码中。然后写下你的发现并在 dzone.com 上发布。或者找到一个 gwt hello world 应用程序（例如，谷歌只是开源 WindowsBuilderPro 作为免费的 GWT IDE）然后在他们的开源示例代码中实现给定页面的 zk 版本。显然，您自己会学到很多东西，并且通过在 dzone.com 这样的好网站上写下来，您将帮助世界。

作为文章 GWT vs. ZK 页面的作者，我不喜欢一种解决方案而不是另一种解决方案。请参阅文章的结论部分。仅供参考，我不再为 Potix Corporation 工作

【参考方案7】：

如果您需要 ZK（服务器端 AJAX 框架）的优势，您可以使用 GWT 和 SmartGWT

【讨论】：

我认为 Vaadin vaadin.com 比 SmartGWT 更接近 ZK 服务器端哲学。