再说ExtJs与WCF之间的跨域访问

在前面文章ExtJs与WCF之间的跨域访问已经通过服务端代理的方式解决了ExtJs与WCF跨域访问的问题,那个方案看起来并不怎么优雅,而当我在写过用Restful方式调用WCF进行上传下载后,愕然发现原来WCF支持原生数据(Raw)的返回,这就解决了ExtJs与Wcf之间进行跨域调用中的难题:返回数据必须满足<script>格式。下面根据ExtJs与WCF之间的跨域访问中实现的项目,通过Stream和ContentType的联合使用,返回原生数据给Extjs,从而实现跨域调用。

第一步:在PageGridService.svc后台代码中,添加操作契约GetProductsByPageCorssDomain,代码为:

GetProductsByPageCorssDomain方法

第二步:在项目中创建一个新的htm页面:PageGridCorssDomainWithRow.htm,代码为:

PageGridCorssDomainWithRow.htm

第三步:在项目中创建一个新的js脚本文件:PageGridCrossDomainWithRow.js

PageGridCrossDomainWithRow.js

接下来,浏览PageGridCorssDomainWithRow.htm,便可以得到如下运行结果:

两种方案对比:

  1. 第一种方案要通过服务端WebClient访问WCF服务,然后由ExtJs访问本地代理页面,这样势必造成一些性能损失。而本文的方式,无须架设服务端代理,由ExtJs直接请求WCF,从操作复杂度上,要低一下,理论上也能因此提高一些性能
  2. 从实现原理上,第一种方式有些背离ExtJs的设计初衷,ExtJS强调用ScriptTagProxy跨域访问数据,但这样对数据格式有一定要求,第一种方案采用绕过拦路虎的方式,通过一个中转将跨域问题化解掉了,虽然效果达到,但毕竟没有充分利用到ExtJs的ScriptTagProxy,而且违背了WCF中的Restful访问方式。
  3. 上面两点都是说明第一种方案的缺点,本文方案的优点,但在现实中,考虑到可用性,还是建议用第一种方式的。本文这种方式虽然有一定优点,却大大破坏了WCF程序结构,使得WCF服务程序开发难度加大,且以后难于维护,因为一个服务,他的使命不光光针对ExtJs一方的调用,他的消费者可能很多,消费方式也不仅仅局限在Restful上,更多需求可能体现在SOAP方式上,他消费者所在平台也可能是linux,这样事情就变的复杂起来,一个返回stream的操作具有普遍性么?对于其他消费者,stream友好么?而且设置了ContentType是不是对其他消费者有致命影响呢?这些问题都是要考虑的,如果是一个面向大众的服务,考虑到上面的问题,纵是有千万种理由,这种方案还是不可取的。相比较一点点的性能,更有些得不偿失!当然具体情况要具体分析,如果是专门为ExtJs或者其他Ajax设计的,那本文方案就比较合理了。

修改后的项目示例: 

posted @ 2008-07-17 20:38  Robin Zhang  阅读(7998)  评论(13编辑  收藏  举报