Using ChannelFactory Vs. Proxies in WCF


I tried researching this area over the net, but couldn’t find a whole lot. So, here’s my blog about it and since this is my very first blog, I’d like to say “Hello World!”


What does it mean to use ChannelFactory?


When you share a common service contract dll between the client and the server, you’ll be using the ChannelFactory class. The idea is to package the service contract interface and your entities in a library, that would be implemented by the service and used by the client.


So if you have a contract such as this in Contract.dll:


 public interface IHelloWorld{


string SayHello(int numTimes);


}


You’d use the ChannelFactory class as follows in the client:


using Contract; 


ChannelFactory<IHelloWorld> channel = new ChannelFactory<IHelloWorld>(“tcp”); //Binding name


When to use a proxy?


We use proxy in WCF to be able to share the service contract and/or entities with the client. If the client to your service is external to the system, such as API, it makes sense to use a proxy, because it makes sharing the contract easier by giving a code file rather than a DLL. 


When to use a ChannelFactory i.e. a shared DLL?


A DLL is helpful if the client code is under you control and you’d like to: share more than just the service contract with the client — such as some utility methods associated with entities and make the client & the service code more tightly bound. If you know that your entities will not change much and the client code is less, then a DLL would work better than a proxy. Proxies have several restrictions like:



  1. Properties need to have gets and sets

  2. Contructors can’t be exposed

  3. Methods other than the service contract cannot be exposed

What all to package in the DLL?


You’ll need to package the following:




  1. Entities


  2. Service contract — the interface


  3. RequestMsg classes (if any)


  4. ResponseMsg classes (if any)

So if you are designing a connected system and using WCF for that, then you can use a shared dll instead of a proxy, to avoid code repetition and be more effective in the use of the service entities.

Comments (12)

  1. Kevin Daly says:

    Is there a binary dependency on the shared dll or could you just use an identically specified interface?

  2. jxk5005 says:

    Hi Kevin,

    Sorry for the late reply, I was on a vacation. Answer to your question is: Yes, you need a shared DLL. The point is that the service and client interact using some objects. If you specify two different interfaces, you’ll need conversion logic from one interface to the other for successful communication. Also, the point of having shared dll is to avoid having duplicate code on the service and client side.

  3. Trach Vo says:

    I have a question about how to get the connection string from web.config which is hosting my WCF Library.

    I have built a service contract in a seperate assembly.  I also have a web site from which I makes a web service reference to my WCF library.  I also have another data layer assembly that WCF library references to it.  The data layer is using LINQ to SQL (.dbml)

    I would like somehow to access the the hosting web.config to get the connection string to pass to the data layer to connect to a seperate database server.

    If you have any idea please help.  Appreciated for help.

    My contact email:  vott@mail.nih.gov

  4. Mahesh says:

    I have a question:  I would like to have a single generic WCF client that can call any WCF object. The client should be able to read config files to create the instances of the WCF object. I do not want to share contract files with the client and once the client (NT Service) is written and deployed I do not want to recompile the client at all. I would like the client to read the connection information of the WCF objects from a config store (database or config files) and be able to call these WCF objects.

    Like a COM client I want to do a QueryInterface, GetIDsOfName etc.. to find the Method.

    Is this possible in WCF? It would be nice if somebody can provide a link to an article that explains how to do this.

    Thanks,

    Mahesh

  5. GAT says:

    Thanks,

    this info was very helpfull :)

  6. Kyryll says:

    Thanks for the info:)

    Oh and Mahesh,

    It sounds like what you want to do is the same thing as the svcutil does but at runtime instead of design time. I would look at decompiling svcutil, Im sure its written in .net :)

    Once you see its inner workings you would be able to mimic that functionality and build interfaces and service clients at runtime, thought I would imagine this would be performance costly.

    Cheers,

    Kyryll

  7. hanu says:

    For intranet applications we need to use channel factory and

    internet applications using service reference, is it right?

  8. Avi says:

    Hi- I would like to know more about why we use channel factory? Is there an option of keeping the message and data contracts in a shared assembly and keep the IService contracts in another. This way we still get to share the data contracts (/r: in svcutil) and get a proxy class generated with Iservicve interface and serviceClient class?

  9. Saurabh Gadkari says:

    This was really helpful !!

    Just what I was looking for to get started. :)

  10. Andrei says:

    What is the impact on versioning when using ChannelFactory class?