When would you ever use In-Proc WCF Components?

Question

I'm studying Juval Lowy's excellent Programming WCF Services and I've just created a really simple in-proc component using his InProcFactory class that comes along with his ServiceModelEx library.

Why would you do this instead of using just regular classes in your project? Using his method requires referencing his library and creating an interface.

I can think of a couple of advantages:

• If you do this consistently you'll reduce coupling considerably.
• Once you've written your in-proc components they're ready to be used out-of-proc or remotely without change.

Are there more advantages in doing this?

Do you write code with in-proc WCF components?

Should all classes be components?

Can you go totally overboard with the whole decoupling thing?

Do the disadvantages of componentizing all your classes outweigh the advantages? Vice versa?

Answer 1

WCF also provides some extra logging and tracing which might come in handy. I think the ability to reconfigure the service as remote (for scalability or whatever) is probably the bigger reason to use this.

Answer 2

If you're subscribed to the IDesign newsletter you would know that Juval has done some performance bench tests with EVERY CLASS as a WCF service. He said that performance was acceptable for a normal business application. Having said that I think there is considerable overhead in terms of learning curve (I.e. if we were all WCF masters it wouldn't be a problem) in doing something like this. You'll also want to do perf. tests for your individual scenario.

So, I think that WCF is one of the ways towards AOP which he mentions in the book however as I've said already practically there is a high learning curve for WCF.