『随笔』WCF开发那些需要注意的坑

执行如下 批处理:
"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 的 稳定性&维护性 远远超过 我之前的 预期

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