相关推荐: 传统Web框架 PK AJAX -来自BJUG邮件列表的讨论 webwork并入struts团队了！ 『讨论』jsonrpc的疑问 WebWork2.2新特性: AJAX之Remote Form (转载) WebWork 2.2: Released and ready for Struts! WebWork2.2新特性(一):数据校验 validator WebWork2.2新特性(系列)---freemark支持多语言
推荐群组: 图灵俱乐部
更多相关推荐
JavaScript Ajax 今天早上在网络上无意看到满江红blog上的这么一篇文章，说出了很大一部分web 开发人员的困惑。这里存在的问题，我觉得有一点是可以作为讨论的前提加以明确的。 web开发现在基本分为：RIA和传统页面导航形式。RIA相对来说，实现难度大一些，因为它既有 传统页面导航形式的特征，又有各种复杂的界面交互以及近乎苛刻的用户交互体验在里面。 前者实现复杂，但是较容易符合以使用为中心的原则，而后一种实现简单，模式较为单一，但是 对于复杂的用户交互缺乏必要的支撑技术，很难实现用户复杂的交互需求。 那么，我们该如何决定项目该上哪一种形式的web app呢？ http://www.javalobby.org/articles/ajax-ria-overview/ 里面提到了几个选择RIA的原则: Simple enough for HTML means that the UI has modest interactivity requirements. However, if any of the following features improves your UI, you should consider RIA technology: * Partial screen updates * Asynchronous communication * Server push * Widgets supporting direct manipulation * Multiple coordinated windows * Modal dialogs * Menus * Keyboard navigation 后面二条可以用DHTML/JS实现。 像满江红blog提到的：根据用户选择的客户ID来判断是否有足够的存款 这个逻辑已经涉及到RIA的应用了，对于它的大部分分析我还是赞同，不过似乎对于这点： 3，客户端基础设施难于与服务器端进行交互。xmlhttp以及web service可选，但是在企业应用中其低下效率可能会带来服务器的压力隐患， 降低性能和吞吐量。若excel方案，则同样面临着与服务器数据交互的难题。不管是xmlhttp方案还是application方案，都面临着抛弃 struts/webwork重新实现request/response dispatch的要求。 对于这点，我存在疑义。其实现有的webwork+dwr+dojo基本可以满足绝大部分RIA需求。简要针对上面提到的几个需求做一个分析： * Partial screen updates --〉webwork很好的支持,targetDiv = "your div". * Asynchronous communication-->WW对form的异步提交和响应作了很好的支持。具体的非form提交的异步 交互可以使用DWR来完成。比如上面提到的用户根据客户ID来判断存款是否充足的异步逻辑。 * Server push --〉DWR支持 * Widgets supporting direct manipulation 期盼DOJO等成熟的客户端组件出现吧 我基本上认为： WW2.2+DWR基本可以实现大部分的B/S结构RIA需求，不过他们的学习曲线比较高。 在具体的应用中，几乎全部的业务逻辑都可以通过后台代码来完成， 而前台的界面交互主要由JS来完成，这里有一个十分谨慎的讨论的禁区： JS可以完成一部分的业务逻辑吗？ 比如相关输入项的计算规则？A+B+C*D = E， 这样的逻辑在前台完成似乎也不是什么难事。然而，会带来一个测试比较难，扩展比较 复杂的问题。打破了这个底线会给前后台一起粘合业务逻辑带来了潜在的隐患。 虽然在具体的项目中，这个地方的设计需要综合的考虑，很多都是相对的。在我们的项目中， 我们将这些计算规则统统放到了后台对应的领域模型身上。然后让DWR传输参数和调用 相应的逻辑，这里涉及到一个性能的问题。这里有一个度的问题，如果性能下降1-5% 可以带来架构上的优雅设计，我觉得是完全可以接受的。