除了Wicket简单性的论点(即Wicket是一个更简单的系统IMHO)和GWT在客户端的响应性(GWT的客户端状态和JavaScript – 可能是复杂的客户端代码)和GWT更大的扩展潜力,有什么争论使用GWT而不是Wicket？
就个人而言,我做了很多Wicket开发,但很久以前只是快速浏览了GWT.
解决方法
基本上,优点是GWT是构建基于javascript的客户端的工具,因此,如果你想要一个基于javascript的客户端,它最适合.
Wicket以服务器为中心,虽然它可以很容易地将javascript嵌入到无状态页面中,但服务器端状态处理是更自然的方法.
必须注意的是,架构非常不同.
使用GWT,您的体系结构将变为客户端 – 服务器,浏览器上的胖客户端,向服务器调用“过程”(服务),发送和接收数据.
使用Wicket(以及其他以服务器端为中心的组件框架,如JSF和Tapestry),架构是一个更“传统”的3层架构,发送和接收的是页面或页面片段,而不是纯数据.
虽然你当然可以将两者结合起来以适应其他架构,但它根本不是很自然.
人们倾向于关注“哪个更容易使用”(这完全是主观的,取决于你的背景),或者“更美丽,有更多组件”,但是人们不应该低估建筑差异,这会影响你的方法必须采取处理安全性和可伸缩性等方面.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
