SilverLight与WCF通信实现

MapleQianerCommon_Demo

上周向项目经理提出了2010项目采用技术的个人意见，其中B/S的客户端，首推微软的SliverLight。对于我来说

，这的确是一项新技术，但是官方和各位热心业内人士无私奉献的各类入门学习资料、进阶提高实例与讲解，以及微软开

发采用技术上手快、易于学习的特点，基于SilverLight开发对我来说又并不陌生，初步接触后，深有似曾相识的感觉。学

习应用她是一个过程，需要经历许多个步骤。初次接触，当然是安装后基于SilverLight开发所有相关的软件环境，这似乎

是几天前的事儿了，离现在很遥远了。

 
 　　在向与大家分享SilverLight与WCF的通信之前，先于大家分享以下2点感受：
1.为什么服务端要选择WCF？
 　　这个理由很简单。首先，WCF是过去所有项目采用的主要技术之一，经过一年多的探索、学习、积累，能够熟练的

应用，具有一定经验。其次，WCF是微软为构建面向服务的应用提供的分布式通信编程框架，整合了.Net平台下所有的和分布式系统有关的技术，例如.Net Remoting、ASMX、WSE和MSMQ。以通信(Communication)范围而论，它可以跨进程、跨机器、跨子网、企业网乃至于 Internet。再次，为了安全考虑和数据库的部署方面，拒绝SilverLight应用程序直接访问数据库。

　　2.SilverLight很强大但不神秘
 作为一个软件技术人员，我一直有个习惯：每每学习一项新技术之前，总会从最底层分析一下原理。SilverLight以浏览器的外挂组件方式提供高度交互性前端应用程序的解决方案，类似与C/S开发模式中的Client，通过TCP或HTTP协议实现与服务端的通信。从这个层面上看，她就是一款可以帮助众多开发人员创造美轮美奂的客户端应用程序，所以她并不神秘。但是，她的确很强大，封装友好的控件，帮助开发人员大大提高了开发效率，降低开发成本；她弥补JavaScript无法实现的诸多步骤，帮助开发人员实现满足客户的视觉效果。

 
在我实现SilverLight与WCF的通信过程中，与众多初学者一样，遇到了以下几个主要棘手问题：
　　a.VS向导生成WCF客户端配置文件ServiceReferences.ClientConfig，程序无法加载
 　　有了去年WCF开发应用的经验，并发现其原原因是配置文件无法加载，那么在创建WCF客户端对象实例时，自行指

定BasicHttpBinding和EndpointAddress即可。为什么指定BasicHttpBinding不是其他Binding方式呢？SilverLight目前仅支持basicHttpBinding方式访问WCF服务。
　　b.SilverLight跨越WCF访问
 　　按照网上方式解决，将以下内容保存为clientaccesspolicy.xml，放在WCF服务的根目录下，并确保可远程访问。
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>　　

　　c.SilverLight动态加载远程WCF服务地址
 　　在网站的web.config文件的appSettings节点中，增加WCF远程服务的配置参数。具体形式如下：
<add key="WcfServiceAddress" value="http://IP:Port/WCFServiceName.svc"/>
在加载SilverLight网页的OBJECT增加
<param name="InitParams" value="WcfServiceAddress=<%=System.Configuration.ConfigurationManager.AppSettings

["WcfServiceAddress"]%>" /> 
 在问题a中，获取WcfServiceAddress参数并实例化EndpointAddress即可。