Your kinda missing the point. Abstracting is not just so you can swap out another tech in its place. In fact, that aspect of abstraction is somewhat of a practical fallacy but that is another thing.
Working with WCF and MSMQ is quite easy. Using the same principles, you can work with TCP without having to know strictly about TCP socket inner workings (although granted it certainly helps) Working with HTTP and WCF is also relatively easy and while WCF can do REST, I would never use it for that. However, SOAP, and the WS-* stack are pretty full featured and not so easy to implement. WCF hides a huge amount of that complexity, one of the major goals of an abstraction. Your specific example, while valid in your scenario, is specific and does not negate its benefits. I have used WCF in many ways in enterprises with great success. I believe there is also a set of relay bindings for the Azure service bus too so you get to use those same concepts again. Having said all that, if you don't like it, don't use it. Perhaps you chose the wrong tech in the first place? - Glav From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors Sent: Saturday, 2 February 2013 9:28 AM To: ozDotNet Subject: Re: SPAM-LOW Re: WCF service best practises On Fri, Feb 1, 2013 at 7:44 PM, Paul Glavich <subscripti...@theglavs.com <mailto:subscripti...@theglavs.com> > wrote: Webapi is a reaction to attitudes as described below. [ ... ] Ofcourse WCF can do REST too, you just have to twiddle a few hundred different knobs on the right way. I would argue WCF is not bullshit. WCF comprises way more than REST and has a very good feature set (albeit with a some implementation flaws). Support for MSMQ, TCP, ServiceBus etc. all via config is no easy feat. >> you want to do an intermittently connected app then use some sort of message queuing framework/system or roll your own And the circle of development life continues... Abstractions are great when they exist for a genuine need. I'd much rather write a computer game against DirectX than whatever nightmare you normally use to talk to GPUs in assembly. I'd rather write a business app in terms of SQL than managing structures on disk myself. The benefit of the scenario with the abstraction vs without is decisive. However when abstractions are thought up by some egg heads in response to a need that doesn't exist, then you end up with something like WCF. The cure is worse than the disease. In the case of the two examples I provided above, the leverage you get from the abstraction is clear. In the case of WCF abstracting rest - why? Even if you wrote your REST calls directly using sockets, it is STILL trivial. If I needed an intermittently connected app to use MSMQ, I could use MSMQ. How many times have you heard of anyone writing an app and then after it is done going "oh shit, we need to change the app to use SMTP instead of TCP sockets." I mean WTF. Seriously. It is an abstraction that doesn't abstraction for added productivity or anything else. Case in point. I recall helping the developer hired by one of our clients get a WCF service up and running on some of our infrastructure. We spent a couple of days beating our heads against why it was failing before finally determining that WCF assumes the existence of an HTTP host header when generating some of its own internal URLs (which is not normally present in on a fixed dedicated IP brinding). Failing that it reverted back to using the machine's netbios machine name in some of its internal comms, which was failing (again, in a high end hosting scenario the internal machine name is never going to resolve on the Internet and normally sit because an app accelerator or firewall etc) . Completely retarded behaviour and purely in existence in and of and because of the abstraction itself. I could have written all of the end-point communication for the project myself in less time than it took to resolve that one issue. In the debrief with the client: <changed to protect the guilty> says: I see what you mean when talking about how WCF can be difficult to work with. It's been a huge learning experience for me. David Connors @ codify.com <http://codify.com> says: It is just too hard for what it does <changed to protect the guilty> says: true -- David Connors da...@connors.com <mailto:da...@connors.com> | M +61 417 189 363 <tel:%2B61%20417%20189%20363> Download my v-card: https://www.codify.com/cards/davidconnors Follow me on Twitter: https://www.twitter.com/davidconnors Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors
