views:

487

answers:

2

This article talks about consuming WCF services in Silverlight, but claims:

There will be no proxies, no generated code, no 3rd party utilities, and no disgusting "Add Service Reference" usage.

What is so wrong with me adding a service reference in my Silverlight project? Are there hidden overheads? Or is it a case of Fear Of Auto Magic on the part of the author?

+2  A: 

The reasoning for that statement from the author appears to be:

To begin, let me start off by reminding everyone that you shouldn't ever use "Add Service Reference" in Visual Studio for magical service client creation. The code is incredibly verbose, hard to manageable, edits are prone to being overwritten, and it's almost always used as an excuse to not actually learn WCF. There are few things worse than having to deal with people who thing they know a product simply because they know how to use a mouse.

As someone who has relied on the "Add Service Reference" in Silverlight exclusively I think that is a bit over the top. I'd agree that the auto-generated code is verbose and it shouldn't be edited because it WILL be overwritten. However as far as manageability goes it doesn't get any simpler, in response to my service changing it takes one click to get the service reference back in sync.

Despite that I think the article is very good and I can vouch that the ease of adding service references has stopped me from delving deeply into WCF. That's not necessarily a bad thing as at the end of the day WCF is plumbing and I'm interested in writing my app not becoming a WCF expert. As it happens I have now reached a point where I am encountering some serialisation issues between Silverlight and my service which I suspect are related to the browser. I'll need to dig deeper into WCF to sort it out and that article looks like th perfect starting point.

The "Add Service Reference" has been fine for me for 1.5 years and while of course there are benefits to learning about the internals of WCF there is definitely nothing wrong with having a quick and simple point and click way to get started from within Visual Studio.

sipwiz
WCF is not just plumbing, you have to acknowledge the service boundary as a special concern in your application, otherwise it becomes transparent and people do silly things. Like trying to share behaviour across service boundaries i.e. Serializing an entire domain model over the wire to bind to UI elements, manipulate and validate and send back to persist to db, chatty rather than chunky conversations with the server and other SOA NO-NOs.
Matthew
A: 

"Adding a service reference" in Silverlight has some problems right now...the config file gets regenerated each time the service is updated.

It goes a little further than the "auto magic" people are stressing as a problem. First, with a service reference you are "coupled" to the service and it's methods it exposes. If you re-generate the service the client has to do the same. Creating the service dynamically alleviates that problem. Furthermore, with abstraction/reflection/Dependency Injection you now have decoupled service references.

I don't think service references are bad, however WCF and web concepts are moving away from it. For example, WCF REST standards have no "service reference" that you consume...its just URL routing tables. More and more people are recommending this as a standard, for example Juwal Lowy (idesign.net and author of a couple WCF books) recommends not using service references as well.

Bart Czernicki