views:

125

answers:

3

My team owns both the WCF service and the Silverlight 3.0 application that will be consuming it.

We do not want to use svcutil to generate proxies as it adds complexity to the development process. We've been down that road before and we're not doing it again.

I've successfully used the ChannelFactory on a WinForms app and I'd like to use it again on this project. The difficulty seems to be that Silverlight expects Begin... and End... methods on the WCF service itself. I can understand that Silverlight might want to make the call asynchronously on a worker thread, but why does my service contract have to change to support this?

I feel like I'm missing something important here, but it's not obvious to me what it is.

Is it really necessary to change the service contract of a WCF service just so it can be consumed by a Silverlight app?

+1  A: 

Well, you need the 'Begin' and 'End' methods on the interface so you have something to call.

That said, the sync v async is a 'local' thing, you can have the server have sync contracts (for the implementation) and the clients have the equivalent async contracts (for Silverlight). This means two different interfaces (or two copies of the same interface that just differ in AsyncPattern=true, if you think of it that way). But basically it's the same "contract" just projected into two different CLR interfaces to provide two different programming models for supply/consumption.

(Does that 'help'?)

(See e.g.

http://blogs.msdn.com/mjm/archive/2005/05/04/414793.aspx

which starts with two CLR interfaces that describe the exact same contract, but offer two different programming models for that contract.)

Brian
Ok, I think I'm grokking it. I can create an async contract, share it with the Silverlight client, use the ChannelFactory to create a channel for the async contract, and use it to call my standard WCF service, which still implements the original sync contract?
pnschofield
@pnschofield: Right.
Brian
A: 

In order for the silverlight UI to remain responsive, there is a design decision that silverlight should only support asynchronos calls.

For using WCF without svcutil have a look at this video: http://www.dnrtv.com/default.aspx?showNum=122

Shiraz Bhaiji
+1  A: 

Although I am using the generated proxy for my current project, I found this document to be helpful if I were to create my own proxy:

Understanding WCF Services In Silverlight 2

You shouldn't need to change the service contract for the WCF service to be consumed by Silverlight.

DaveB