|
锁定老贴子 主题:一个成功的RIA技术需要满足的条件
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
时间:2007-05-05 关键字: RIA
不要将自己完全局限在现有技术的能力范围内,来跟我一起预测一下未来技术的发展趋势,看看一种理想的RIA技术应该满足哪些条件。我先来开个头。
1. 与服务器的交互方式必需首先支持异步的交互。异步的交互才不会打断用户的操作。当然也可以同时支持同步的交互。 2. 所基于的新的媒体格式必需是基于文本的,这样的格式才可能对于搜索引擎友好。 3. 要能够充分支持REST风格的架构设计,允许开发者充分利用所有HTTP协议的基础设施(各种HTTP方法、HTTP头信息、HTTP Cookie)。 4. 要有足够好的性能。 5. 要能够支持增量的呈现(incremental rendering)。 6. 要具有丰富的UI组件库。 7. 要基于动态类型的脚本语言,例如JavaScript或ActionScript,而不是C#这样的静态类型语言。 8. 要有90%以上的客户端部署比例。这样才能保证很好的Web可访问性(Web Accessibility)。 9. 要能够跨平台,即:跨浏览器和操作系统。 10. 要有较为强大的开发工具。 11. 开发和部署的成本不能太高。例如,假如Flex开发的应用部署时必须要使用Flex服务器,一个license买5万元,那么在国内就不可能有很多人用。 目前Ajax、Flex/Apollo、WPF都没有满足上述所有的条件。 声明:JavaEye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
|
|
| 返回顶楼 | |
|
时间:2007-05-05
dlee 写道 不要将自己完全局限在现有技术的能力范围内,来跟我一起预测一下未来技术的发展趋势,看看一种理想的RIA技术应该满足哪些条件。我先来开个头。
1. 与服务器的交互方式必需首先支持异步的交互。异步的交互才不会打断用户的操作。当然也可以同时支持同步的交互。 2. 所基于的新的媒体格式必需是基于文本的,这样的格式才可能对于搜索引擎友好。 3. 要能够充分支持REST风格的架构设计,允许开发者充分利用所有HTTP协议的基础设施(各种HTTP方法、HTTP头信息、HTTP Cookie)。 4. 要有足够好的性能。 5. 要能够支持增量的呈现(incremental rendering)。 6. 要具有丰富的UI组件库。 7. 要基于动态类型的脚本语言,例如JavaScript或ActionScript,而不是C#这样的静态类型语言。 8. 要有90%以上的客户端部署比例。这样才能保证很好的Web可访问性(Web Accessibility)。 9. 要能够跨平台,即:跨浏览器和操作系统。 10. 要有较为强大的开发工具。 11. 开发和部署的成本不能太高。例如,假如Flex开发的应用部署时必须要使用Flex服务器,一个license买5万元,那么在国内就不可能有很多人用。 目前Ajax、Flex/Apollo、WPF都没有满足上述所有的条件。 补充几条: A: 能够建立一套RIA标准,并且至少有一家具备绝对实力的公司能够有一个完整的,稳定的实现。目前看好Adobe B: UI组件库能够比较方便的做扩展 C: RIA框架本身能够比较方便的做扩展 |
|
| 返回顶楼 | |
|
时间:2007-05-05
我则看好silverlight~~
|
|
| 返回顶楼 | |
|
时间:2007-05-05
我的观点是这样:能够推动RIA发展的人,一定是好的交互式设计师,是懂得用户需要的人。让程序员从技术的角度讨论RIA的好处是没多大意义的,程序员擅长解决的问题是如何同机器打交道,而RIA的关键问题是如何与人打交道。
|
|
| 返回顶楼 | |
|
时间:2007-05-05
treenode 写道 我的观点是这样:能够推动RIA发展的人,一定是好的交互式设计师,是懂得用户需要的人。让程序员从技术的角度讨论RIA的好处是没多大意义的,程序员擅长解决的问题是如何同机器打交道,而RIA的关键问题是如何与人打交道。
这一点上面,客观地说,美工出身的较有优势吧 |
|
| 返回顶楼 | |
|
时间:2007-05-05
treenode 写道 我的观点是这样:能够推动RIA发展的人,一定是好的交互式设计师,是懂得用户需要的人。让程序员从技术的角度讨论RIA的好处是没多大意义的,程序员擅长解决的问题是如何同机器打交道,而RIA的关键问题是如何与人打交道。
这两者是不矛盾的。更好的技术,更高的生产力,有助于程序员拥抱变化,为最终用户提供更好的交互体验和服务。当然,在团队中如果有一个专业的交互设计师(可以在专业的美工中发展),做出来的产品会有明显的不同。 |
|
| 返回顶楼 | |
|
时间:2007-05-05
dlee 写道 treenode 写道 我的观点是这样:能够推动RIA发展的人,一定是好的交互式设计师,是懂得用户需要的人。让程序员从技术的角度讨论RIA的好处是没多大意义的,程序员擅长解决的问题是如何同机器打交道,而RIA的关键问题是如何与人打交道。
这两者是不矛盾的。更好的技术,更高的生产力,有助于程序员拥抱变化,为最终用户提供更好的交互体验和服务。当然,在团队中如果有一个专业的交互设计师(可以在专业的美工中发展),做出来的产品会有明显的不同。 RIA并没有解决程序员生产力的问题,从目前的情况看,再好的RIA开发工具最多也只能做到像Delphi程序员拖拉出来一个界面那样的效率。 而且表现层目前还有两大难题是任何技术都没能从根本上解决的: 1.如何对界面进行有效的测试? 2.如何对界面进行渐进式的重构? 这两个问题不解决的话,表现层的开发根本无法敏捷起来。 |
|
| 返回顶楼 | |
|
时间:2007-05-05
JJYAO 写道 A: 能够建立一套RIA标准,并且至少有一家具备绝对实力的公司能够有一个完整的,稳定的实现。 这一条我是坚决反对的。RIA目前还是不成熟的领域,在这个领域试图建立标准,很可能出来一个类似EJB的、所谓专家拍脑袋想出来的的空中楼阁,落一个被人革命的下场。 |
|
| 返回顶楼 | |
|
时间:2007-05-06
treenode 写道 RIA并没有解决程序员生产力的问题,从目前的情况看,再好的RIA开发工具最多也只能做到像Delphi程序员拖拉出来一个界面那样的效率。
而且表现层目前还有两大难题是任何技术都没能从根本上解决的: 1.如何对界面进行有效的测试? 2.如何对界面进行渐进式的重构? 这两个问题不解决的话,表现层的开发根本无法敏捷起来。 1. RIA能够实现的一些交互,是单靠传统的服务器端开发框架难以实现的。如果不通过RIA技术,开发工作量会大的多,而且还无法达到理想的效果。 2. RIA对于Web表现层开发效率的提升是明显的。我接触过所有用过Flex的朋友都有明显的体验,这一点你不需要怀疑,RIA对于Web表现层开发敏捷化是很有帮助的。 下面我专门说一下RIA应用的测试。 RIA应用的测试,可以分成3个层次:代码级的单元测试、功能级的验收测试、界面和交互体验的测试。 以Ajax开发为例。要做好这3个层次的测试,有一个非常重要的原则是一定要将页面中的结构、表现和行为3部分严格分离开,另外使用的UI组件一定要尽量的Unobtrusive。假如无法有效地将页面的这3部分分离开,就无法进行有效的测试。这3部分分离开之后,就可以使用JSUnit针对页面中的行为代码做自动化的单元测试,也可以使用Selenium对于页面的整体功能进行自动化的验收测试。JSUnit和Selenium都是非常棒的工具,目前在Ajax开发者中使用的越来越多了,建议你不妨一试。能够自动化的只有这两部分,界面和交互体验的测试肯定是只有交互设计师手工来做了,当然交互设计师提出要求,由程序员来测试也是可行的。 对于其他的RIA技术,上述的这个原则依然适用。一定要将界面中的结构、表现和行为3部分严格分离开,这是对于界面进行有效测试的关键。这3部分分离开之后,就可以逐渐形成自己的一套组件库,逐渐提升重用的范围和层次,你所说的渐进式重构也就不是问题了。 简而言之,其实你的想法早就有很多人努力在解决了,并且取得了很明显的效果。你不去了解和尝试,仅仅是一味等待,理想的完美世界是不可能到来的。 |
|
| 返回顶楼 | |
|
时间:2007-05-06
treenode 写道 这一条我是坚决反对的。RIA目前还是不成熟的领域,在这个领域试图建立标准,很可能出来一个类似EJB的、所谓专家拍脑袋想出来的的空中楼阁,落一个被人革命的下场。
这个观点我完全同意。委员会驱动的技术发展道路绝对不能在RIA领域复制,况且Web表现层开发的市场太大了,完全可以同时容纳3、4种优秀的技术,它们都能取得较为理想的发展。我们可以在这里帮助开发者根据自己的实际情况选择最适合于自己的技术,这正是我列出上面这些需要满足的条件的原因。我感觉目前国内的很多人的观点都不够全面,往往仅仅因为某种RIA技术一个方面的优点就将其他技术完全排斥。例如: 仅仅因为开发效率就排斥Ajax。知道吗?其实Ajax开发也是可以很敏捷的。 仅仅因为搜索引擎优化就排斥Flash。 仅仅因为反对M$就排斥WPF,或者仅仅因为崇拜M$就推崇WPF,鄙视Ajax、Flex/Apollo。 诸如此类。 |
|
| 返回顶楼 | |










