2

我们计划在客户端富接口和在服务器端返回 JSON 数据的 Spring MVC 使用智能 GWT、GWT 和相关框架。

作为调查的一部分，看看它是否符合我们的要求，以下问题需要一些答案：

  1. 在不使用任何框架的情况下从头开始构建 GWT 应用程序需要付出大量努力才能遵循标准 MVP 模式。但这更灵活且可单元测试，虽然很耗时。GWT 最佳实践建议使用 MVP 设计模式来构建更大的应用程序。

SmartGWT 有它自己的方法，您可以在其中使用一个小部件，将一个数据源引入其中，然后您就完成了。尚未确定以模块化（或 MVP）方式构建此类智能 GWT 组件的最佳实践。有什么建议么

  1. 使用框架 GWT-platform 和 SmartGWT 可能是尝试这里提到的 MVP 架构的一个选项。有什么建议么？

  2. 智能 GWT 的验证/消息/异常显示和其他通用功能支持还有待研究。

  3. 客户端服务器架构：服务器端有 Spring MVC + Spring core，客户端有 GWT + Smart GWT 可能是一个很好的开源技术堆栈，但鉴于 GWT 默认使用 RPC 进行客户端服务器交互，这些需求的使用以便更好地评价。（尤其是身份验证/会话处理/安全等）。有什么建议么？

谢谢

4

3 回答 3

2

我神经质地使用 SmartGWT 或任何其他丰富的库。我的观点可能有偏见，但我真的认为 Gwt 组件易于定制和轻量级。这是我从未觉得来自 SmartGwt 的任何其他类型的图书馆。

话虽这么说，这是我对您关心的两个问题的回答：

使用框架 GWT-platform 和 SmartGWT 可能是尝试这里提到的 MVP 架构的一个选项。有什么建议么？

好吧，要在这方面保持 MVP，只需从演示者设置数据源。在您看来，SmartGWT 小部件应该是“被动的”并等待来自演示者的配置。

优点：您不必对视图进行单元测试，因为 SmartGWT 小部件应该已经过很好的测试。您只需要测试您实际调用视图的演示者来配置该小部件并验证您是否正确调用它。

客户端服务器架构：服务器端有 Spring MVC + Spring core，客户端有 GWT + Smart GWT 可能是一个很好的开源技术堆栈，但鉴于 GWT 默认使用 RPC 进行客户端服务器交互，这些需求的使用以便更好地评价。（尤其是身份验证/会话处理/安全等）。有什么建议么？

RPC 是一个选项，而不是默认通信。还有另外两种类型的通信（如果您尝试像 DeRPC 这样的实验性功能，甚至更多）：RequestBuilder 和 RequestFactory。

RequestBuilder 可以用于带有 JSON 响应的 HTTP GET。无法帮助您使用智能 GWT 方法。

这是一个使用 Smart GWT 的 Gwt-Platform 用户，阅读他的博客，应该会启发你： http ://uptick.com.au/blog

在撰写此答案时，博客已关闭，但应该很快就会恢复。

于 2011-02-28T14:52:39.383 回答
0

您应该首先考虑使用 MVP 的目标。

如果您查看 SmartGWT 示例，您会发现它们已经有了清晰且最少的代码。您无法通过引入 MVP 来简化或阐明任何示例，您只能添加额外的代码和复杂性。

因此，您应该有一个非常具体、具体、非常有说服力的理由来说明为什么要使用 MVP 并引入额外的代码：一个特定的设计目标，不能通过正常使用 SmartGWT 以更简单的方式实现。

很难找到这种有效的目标，因为 SmartGWT 非常灵活并且已经支持通过 Selenium 进行测试，甚至还有 Selenium IDE 扩展和对 Selenium RC 的支持。

追求 MVP 的正当理由的一个可能示例可能是拥有两个完全独立的视图实现，一个在 SmartGWT 中，一个在普通 GWT 中简化。我知道，这不是一个很好的例子，很难想象有人需要这样做，但那是因为除了非常模糊的灵活性概念之外，我们还没有任何开发人员出现并阐明将 MVP 与 SmartGWT 一起使用的理由。

如果您要承担使用 MVP 的任务，我认为您应该充分了解情况，可以说“我们需要做 X，如果我们正常使用 SmartGWT，这将需要 6 个月，如果我们添加 MVP，这将需要 3 英寸。据我所知，没有人发现过这种情况。

于 2011-02-28T19:10:41.817 回答
0

我目前正在开发一个 Smart GWT / GWT 应用程序。

我目前对 Smart GWT 的看法是，它确实节省了大量时间，并且提供了一些好看、有用的小部件。也就是说，因为它是 JavaScript 库的包装器，所以它确实有一些警告，尤其是在调试时。通常，与使用纯 GWT（或带有不是 JavaScript 包装器的库的 GWT）相比，跟踪错误要困难得多。

要尝试评论您的问题：

  1. 我还没有发现 Smart GWT 库在这方面是个问题。它可能与 GWT 推荐的方式不同，但这并不意味着您突然不得不放弃所有最佳实践。

  2. 不能对此发表评论 - 还没有发现验证/消息/异常库是一个问题

  3. 我们使用 JAX-RS 进行客户端/服务器通信，Smart GWT 原生支持并且非常容易实现。它可能比 GWT RPC 更容易调试，因为它使用 XML 格式。我们只是使用 Spring Security 来保证安全性，同样没有问题。

我认为对我们来说，让我再次考虑使用 Smart GWT 的主要因素是可定制性：例如，当您使用它们的表单时，就布局而言，您不能对它们做太多事情。Smart GWT 有自己的做事方式，除非您想编写自己的组件（这并不理想，因为 Smart GWT 不建议将 Smart GWT 和普通 GWT 组件混合使用），否则您几乎被锁定在这种方式中。

如果您乐于编写一个使用 Smart GWT 库且不需要太多自定义的应用程序，那就没问题了。

于 2011-02-28T09:47:06.380 回答