我们计划使用智能GWT，GWT和相关框架用于客户端丰富的接口，以及在服务器端返回JSON数据的Spring MVC。
作为调查是否符合我们要求的一部分，需要回答以下问题：
- 在不使用任何框架的情况下从头开始构建 GWT 应用程序需要付出大量努力才能遵循标准 MVP 模式。但这更灵活且可进行单元测试，尽管很耗时。 GWT 最佳实践建议使用 MVP 设计模式来构建更大的应用程序。
SmartGWT 有它自己的方法，您可以使用一个小部件，向其中引入一个数据源，然后就完成了。尚未确定以模块化（或 MVP）方式构建此类智能 GWT 组件的最佳实践。有什么建议
使用框架 GWT-platform 和 SmartGWT 可能是尝试此处提到的 MVP 架构的一种选择。有什么建议么？
智能 GWT 的验证/消息/异常显示和其他通用功能支持还有待研究。
客户端-服务器架构：服务器端拥有 Spring MVC + Spring core，客户端拥有 GWT + Smart GWT 可能是一个很好的开源技术堆栈，但考虑到 GWT 默认使用 RPC 进行客户端服务器交互，这些需求的使用以便得到更好的评价。 （特别是身份验证/会话处理/安全等）。有什么建议么？
Thanks
我从来没有使用过 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 http://uptick.com.au/blog
在撰写此答案时，博客已关闭，但应该很快就会恢复。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
