WCF之操作重载

• 服务契约的方法重载,会在装载宿主时,抛出异常.
  • 解决是在操作契约上Name设置为不同值,但是生成的代理会把Name的名称作为方法的名称,不过我们可以手动的修改代理类,使得方法名与服务声明的名称一样.
• 契约的继承: 服务契约是不可继承的.
  • 客户端在导入服务契约时，会取消服务契约的继承层级，并利用OperationContract特性中的Action与ReplyAction属性，保留原来定义每个操作的契约名。
  • 但为了使客户端编程能够与服务编程保持一致，最好是恢复客户端的契约层级。即根据服务契约层级对客户端契约进行手工修改.
• 服务契约的分离和设计.
  • ISP原则建议使用多个专门的接口，而不是使用单个接口，这样可以防止接口污染，有利于接口重用.同理,合理的契约分解可以实现深度特化、松散耦合、精细调整以及契约的重用。这些优势有助于改善整个系统。
  • 总的来说，契约分解的目的就是使契约包含的操作尽可能少.
• 设计面向服务的系统时，需要平衡两个影响系统的因素:一个是实现服务契约的代价，一个则是将服务契约合并或集成为一个高内聚应用程序的代价.
• 准属性操作（Property-Like Operation）的使用.
  • 就是如果涉及到对对象状态的管理（在C#中一般体现为属性），则这样的操作不宜被公开为服务操作。原因在于：“客户端应该只负责调用操作，而由服务去管理服务对象的状态.
• 契约查询: 首先要了解元数据的信息.
• 面向对象有两个原则:依赖倒置原则强调的是实现依赖于抽象,抽象不依赖于实现 ,而Liskov原则强调的是子类必须可以替换其基类.
• WCF通讯双方存在明显的边界.服务端所设定的契约关系层次和数据的继承关系不能强制的适用于客户端，这充分体现了面向服务的松散耦合的特征，虽然有悖于OO的设计原则，但也恰恰体现了面向服务的优点，且这种做法更适应变化.
• 异步
  • WCF中实现异步是一件非常简单的事情,我们用svcutil来生成客户端代理代码的时候,只需添加/async 便可以生成有异步功能的代理类了.而在IDE中,操作就更加简单,就是在添加ServiceReference的时候,选择高级选项,钩选Generate Asynchronus operations.
  • 服务操作究竟是否采用异步方式，应该由客户端的调用者决定。因此，所有与异步调用相关的内容应该只与客户端相关。WCF遵循了这一规则。在客户端决定采用异步方式调用我所设计的服务操作时，虽然需要修改客户端的服务契约接口，但并不会影响服务端的契约定义。对于异步调用的完成，虽然WCF提供了诸如阻塞、等待和轮询等机制，但最好的方式还是使用回调。也就是利用Begin方法参数中的AsyncCallback对象。由于回调方法并非运行在主线程中，如果回调方法需要更新与异步调用结果相关的界面，例如本例中的lbMessage控件，则需要将回调的调用封送(Marshal)到当前主程序界面的同步上下文中。我们可以使用SynchronizationContext以及它的SendOrPostCallback委托，对调用进行封送.