首页 > 代码库 > WCF开发那些需要注意的坑 Z

WCF开发那些需要注意的坑 Z

执行如下 批处理:
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\svcutil.exe" http://127.0.0.1:40001/TestService?wsdl /language:C# /out:"D:\TestProxy.cs" /config:"app.config"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\svcutil.exe" http://127.0.0.1:40001/TestService?wsdl /language:C# /out:"D:\TestProxy.cs" /config:"app.config"

就能在 D盘 得到 代理类 & 配置文件片段

——————————————————————————————————————————————————————

关于 WCF的 传统用法 几点忠告:

  >WCF不支持 List 等一切 集合类型 (一切集合 都会被 WCF 转换为 数组)
  >WCF不支持 Hashtable 等大部 哈希类型 (大部哈希 都会被 WCF 转换为 Dictionary<object,object>)
    ——部分特殊情况 WCF 连 Dictionary<object, object> 都不支持
  >注意在 服务端 对 需要的对象 声明特性 : [KnownType(typeof(TestVModel_User))]


  >建议: WCF穿透对象 尽量不要出现 List 和 Hash —— 可以的话 尽量用 T[] 和 Dictionary<K, V>
  >警告: 使用 Hashtable 就是一个 不折不扣 的 埋坑行为。


——————————————————————————————————————————————————————

关于 WCF的 另类用法 几个方案:
  PS: "穿透实体" = "视图实体"
  "数据实体" 指 保存有效数据的 实体对象


  >方案一 : WCF 传统用法 : 写服务端、生成客户端代理类
    >优势 :   代码简单;
         用 穿透实体 保护 数据实体;
    >劣势 :   数据类型 狭隘; 存在 不稳定因素;
         服务端改变, 所有 客户端代理类 需 重新生成 (最难维护 的 环节);


  >方案二 : WCF 穿透对象 只使用 byte[]
    >优势 :  通讯量小,速度快,类型广泛,数据稳定;不需要重新生成 代理类;
    >劣势 :  byte[] 反向解析 问题:
          >如果 是 反序列化 :则 要求客户端 存在 实体类程序集 —— 无法保护 数据实体;


  >方案三 : WCF 穿透对象 只使用 string
    >优势 : 通讯量小,速度快,数据稳定,跨Java等平台,不需要重新生成 代理类;
    >劣势 :  >只能兼容 XML 和 JSON 类型 —— 类型依然狭隘;
        >string 明文, 可能存在 安全问题;
        >需要客户端 反解析 JSON 或 XML 字符串 —— 代码多了一点;


  >方案四 :  >系统内网电脑 WCF 使用 byte[] —— 共享 实体类程序集
       >系统外网电脑 另外开辟 Web服务, 另外开辟 穿透实体;
    >优势 : 在 有安全机制 的 内网, 使用 稳定快速的 方式;
    >劣势 : 在 有风险   的 外网, 使用 另外的暴露 方式;

 

  最后 : 实体类程序集
    >只包含 视图实体类, 字段属性 —— 结构简单;
    >并不包含 逻辑代码, 被外部引用 —— 真的会有 安全风险 么?

 

  当然, 任何一种方案, 难度都差不多 —— 更多的都是 后期维护的 难度不同;

——————————————————————————————————————————————————————

关于 WCF的 维护测试:

  >如果 没有标记 [DataMember] :
  >如果 部分标记  [DataContract] 和 [DataMember] —— 则未标记 属性 会丢失(不会出现在 代理类中)
  >如果 不标记任何 [DataContract] 和 [DataMember]
    >且 不标记 [Serializable] —— 完全正常
    >若 标记  [Serializable] —— 所有属性名 都会被加上 __BackingField 后缀


  >如果 增加/减少 穿透对象的属性 :
    >减少 穿透对象 属性, 但是 代理类却没有更新 —— 客户端一切正常, 减少属性 无值
    >增加 穿透对象 属性, 但是 代理类却没有跟新 —— 客户端一切正常, (代理类 ExtensionData 有增加值)


  >如果 增加/减少 服务函数 :
    >如果 增加 服务函数 :
      >如果 新函数 返回 新穿透对象, 但是 代理类却没有更新 —— 客户端 在不掉用新函数时(客户端根本就没有新函数) 一切正常
    >如果 减少 服务函数, 但是 代理类却没有更新 —— 客户端 在不调用删除函数时 一切正常


  >如果 函数参数列表 增加/减少 函数参数 :
    >增加服务函数 末尾参数, 但是 代理类却没有更新 —— 客户端一切正常, 新参数 无值 (我已经被 彻底 雷死了)
    >新增服务参数 乱序参数, 但是 代理类却没有更新 —— 客户端一切正常, 新参数 无值 (我已经被 完全 雷死了)
    >减少服务参数 任意参数, 但是 代理类却没有更新 —— 客户端一切正常, 新参数 无值 (我已经被 无语了)
    >打乱服务参数, 但是 代理类却没有更新 —— 客户端传入参数 异常 :
      >如 :
      >最开始 服务端、客户端 参数表: testArg, testArg2, testArg3
      >服务端 修改为 testArg2, testArg, testArg3 —— 则 服务端 仅有 testArg testArg3 有值
      >服务端 修改为 testArg, testArg3, testArg2 —— 则 服务端 仅有 testArg testArg2 有值


  >结论 : WCF 的 稳定性&维护性 远远超过 我之前的 预期