再说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 @   Robin Zhang  阅读(7998)  评论(13编辑  收藏  举报
编辑推荐:
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· AI技术革命,工作效率10个最佳AI工具
点击右上角即可分享
微信分享提示