The caching mechanism of channelfactory<t> in the eight:clientbase<t> of WCF technology analysis

As with traditional distributed remote calls, WCF service invocations are aided by service proxies. Channelfactory<t> is the creator of the service proxy. WCF uses endpoint based (Endpoint) service consumption: WCF services are exposed to potential service consumers through one or more endpoints, and service consumption is interacted with by matching endpoints. On the client side, we have two typical ways of service proxy creation, one of which is to import the metadata of the service through tools such as SvcUtil.exe to generate the corresponding service proxy (a type that inherits from clientbase<t>) code and related configuration The second is to create the Channelfactory<t> object directly from the appropriate endpoint information (specified or configured by code) and use the object directly to create the service proxy.

In fact, even if a service invocation is made through the Clientbase<t> object, it is internally called the service proxy created by the channelfactory<t>. The creation of the entire channelfactory<t> is a relatively complex and time-consuming task that involves many operations such as reflection, reading of configuration files, and so on. To improve the performance of service invocations, in. NET 3.5, WCF introduced the channelfactory<t> caching mechanism in clientbase<t>.

First, how to implement the cache of channelfactory<t>

To give readers an intuitive understanding of the channelfactory<t> caching mechanism, let's do a simple experiment: Execute the following code in a console application, Where calculatorclient can be considered as a custom service proxy class at the beginning of this section. In this case, two Calculatorclient objects are created and opened in the same way (calling the same constructor, passing in the same argument), and then verifying that their channelfactory is the same object.

   1:calculatorclient proxy1 = new Calculatorclient ("Calculateservice");
   2:proxy1. Open ();
   3:calculatorclient Proxy2 = new Calculatorclient ("Calculateservice");
   4:proxy2. Open (); Console.WriteLine ("Object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory) = {0} ",
   5:object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory));

Output results:

   1:object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory) = True

From the results of the output, you can see that two different clientbase<t> objects use the same Channelfactory<t> object. This benefits from the caching mechanism of the newly added channelfactory<t> in. NET 3.5. So how does the cache of channelfactory<t> within the WCF client framework be implemented?

In fact, the,channelfactory<t> cache implementation is simple, and the created channelfactory<t> set is saved by a static variable clientbase<t>. We can consider this channelfactory<t> set as a dictionary, the value of which is channelfactory<t>, and the key is derived from the following three objects:

callbackinstance: Encapsulation of a callback object represented by a InstanceContext object;

endpointconfigurationname: The name of the endpoint in the compounding file;

remoteaddress: The remote address of the endpoint, the type is endpointaddress.

They match the corresponding parameters in the Clienbase<t> constructor, respectively. When a constructor is invoked to create an object, WCF takes the three arguments passed in as key (if the constructor does not specify the corresponding parameter, the default value is used, Endpointconfigurationname, The default values for Callbackinstance and remoteaddress are *, NULL, and NULL, respectively, to find a matching channelfactory<t> object from the cache (static variables), and if it is successfully found, to return it directly, otherwise recreate , and puts it in the cache before returning.

In this sense, multiple clienbase<t> objects can reuse the same Channelfactory<t> object if they use the same constructor and pass in the same parameter to be created. To verify this, and then to do an experiment, you just need to modify the example above to create the Calculatorclient object by using another overloaded constructor.

   1:calculatorclient proxy1 = new Calculatorclient ("Calculateservice", New EndpointAddress ("http://127.0.0.1:9999/ Calculateservice ");
   2:proxy1. Open ();
   3:
   4:calculatorclient Proxy2 = new Calculatorclient ("Calculateservice");
   5:proxy2. Open ();
   6:console.writeline ("object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory) = {0} ",
   7:object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory));
   8:

Output results:

   1:object. ReferenceEquals (Proxy1. ChannelFactory, Proxy2. ChannelFactory) = False

In fact, the endpoint addresses that Proxy1 and Proxy2 end up using are the same (Http://127.0.0.1:9999/calculatorservice), except that one is specified by code and the other is configured through a configuration file. However, the same Channelfactory<t> object cannot be reused because a different constructor overload was used when the clienbase<t> was created.

Channelfactory<t> reuse avoids frequently common channelfactory<t> objects for better performance. In the specific application, we should use this mechanism as much as possible. However, because programmers do not understand the caching mechanism of channelfactory<t>, this caching mechanism will be invalidated. Let's discuss the issue next.