代码下载:点我 作为备份
Artech的代码要在他的博客里面找的
Artech大师级的“总分总”式的风格,的确是和高手过招用,作为一面菜鸟,纠结了老半天才明白,原来写博客也可以前后呼应
于是把这个小节点整理到一起已被以后不时只需
5 、自定义CallContextInitializer (Step 12 & Step 18)
提到CallContextInitializer,我想有一部分人会马上想到System.Runtime.Remoting.Messaging.CallContext。CallContext为我们创建基于当前线程的Ambient context提供了便利。通过CallConext,我们和容易地将一些contextual information保存在TLS(Thread Local Storage)中。
类似地,DispatchOperation的CallContextInitializers提供了一个 CallContextInitializer的集合,这些CallContextInitializer可以帮助我们对TLS进行初始化和释放回收的工作。比如在某个service 方法被真正之前,我们希望设置一些Context的数据,这些数据可能使业务有关,但大部分是和具体的业务逻辑没有关系的,比如一些Auditing的数据。在方式执行完成后,对这些context数据进行清理和回收。 WCF下的所有CallContextInitializer实现了System.ServiceModel.Dispatcher.ICallContextInitializer interface:
public interface ICallContextInitializer { // Methods void AfterInvoke(object correlationState); object BeforeInvoke(InstanceContext instanceContext, IClientChannel channel, Message message); }
再给大家介绍一个使用CallContextInitializer的场景。假设有一个service专门提供 message,考虑到Localization,当客户访问你的service获取某项message entry的时候,你希望根据该client的当前culture/UI culture返回具体的message。但是你不希望将这个culture作为API的一部分。这样你就可以这样做:在client端,通过自定义ClientMessageInspector将当前的Culture附加到outgoing message的header中。在service端,通过一个自定义的CallContextInitializer,将culture的值从incoming message header取出,并用这个culture设置当前线程的Culture和UICulture。那么message的获取只需要考虑当前线程的Culture就可以了。我将在本系列后续的文章介绍这个应用。
剩下的地方在Artech这里:点我
看Artech文章时,一直在郁闷,到底什么是扩展?为什么介绍了一个接口,又介绍一个接口,知道把文章全部看了一边,虽然没看懂,才知道这家伙小时候写作文喜欢“总-分”式,
wcf整体来说的结构模型感觉和iis是一个思想的产物,都是管道模型,然后信息和数据从这个管道留到另外一个管道,
扩展的地方主要是要弄清楚3点
1:要扩展哪一个环节
2:扩展的这个环节要解决什么问题
3:扩展的这个环节如何附加到管道和管道的交界处
对与CallContextInitializer扩展防范只有一个
但将扩展应用到管道有两种方式
1通过OperationBehavior应用CallContextInitializer
2通过EndpointBehavior运用CallContextInitializer
而通过EndpointBehavior将扩展附加到管道上时可以配置的相对来说较为灵活
Artech的例子也是这么做例子的