Clever Geek Handbook

When will you ever use WCF In-Proc components?

I am learning excellent WCF programming Juval Lowy and I just created a really simple in-proc component using his InProcFactory class that comes with his ServiceModelEx library.

Why would you want to do this instead of just using 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 will significantly reduce grip.
  • After you have written your in-proc components, they are ready to be used outside the procedure or remotely without modification.

Are there more benefits to this?

Are you writing code with WCF components in proc?

Do all classes have to be components?

Can you go all the way overboard with all the interchange?

Do components of all your classes eliminate the disadvantages of the advantages? And vice versa?

+1


source to share


2 answers


If you are subscribed to the IDesign newsletter, you would know that Juval has run multiple performance tests with EACH CLASS as a WCF service. He said the performance is acceptable for a typical business application. Having said that, I believe there is significant overhead on the learning curve (for example, if we were WCF masters it wouldn't be a problem) doing something like this. You will also want to do perf. tests for your individual scenario.



So I think WCF is one way for AOP that he mentions in the book, however, as I said, there is practically a learning curve for WCF.

+2


source


WCF also provides some additional logging and tracing that might come in handy. I think the ability to reconfigure the service as remote (for scalability, etc.) is probably a big reason to use this.



+2


source






More articles:


All Articles