0

As I read here http://arunatennakoon.blogspot.com/2010/11/things-i-learn-new-this-week.html

Friday, November 12, 2010
Things I learn new this week
1. Never ever use WCF.
---------------------

here is why
1. IIS 7 doesn't support .svc file format by default. So you need to

install some extension files. so it's lot of work for a new product.

2. I found it very hard to configure security settings. when i

tried to configure for the first time it threw all kind of errors.

3. After installing WCF in IIS, sometimes it's trowing an exception

that refers to the temp directory. To solve this problem you have to re compile the application and re-distribute

and a lot more...

So would you take the risk to use WCF ?

I'd like to hear about real world examples with hundred to billions of hit per year.

user310291
  • 36,946
  • 82
  • 271
  • 487
  • 5
    I see you accepted the one answer which chimed with the ill-informed and shallow prejudices voiced on the blog you referenced, and which one suspects you share. Your choice, your loss. The fact is that many all over the world are getting great value out of WCF. If you want to deny yourself that without even evaluating it properly, go ahead. – Chris Dickson Dec 18 '10 at 15:08
  • It depends on project you work if performance is really a key you have to sacrifice abstraction. The problem with all these abstractions is that they don't tell you HOW it really works so that you can balance. So I agree with this article http://www.bluebytesoftware.com/blog/2010/09/06/ThePrematureOptimizationIsEvilMyth.aspx but when you're not a MS Insider or you are project manager who have contradictory opinions you choose the less risky one. – user310291 Apr 10 '11 at 09:36

10 Answers10

5

It is definitely ready for real world. Even Microsoft uses it in its products, for example MS Dynamics CRM services are now done in WCF.

TarasB
  • 2,407
  • 1
  • 24
  • 32
  • That Microsoft uses it is not a real proof as when they have problem with their stuff they can easily hack it whereas when YOU or ME have a problem you cannot go INSIDE the box ... :) – user310291 Dec 14 '10 at 00:05
  • 2
    @user310291 Since WCF is managed code, actually we can ALL go inside the box - with ILDASM or Reflector - when we need to. WCF is also very extensible, so we can control just about every aspect of what it does if we need to. – Chris Dickson Dec 17 '10 at 16:19
  • Going inside the box with ILDASM is to become a hacker. For enterprise world this is not good QA as a technology must not require an average developer to become a hacker especially as he has a lot of stuffs to do at business level. – user310291 Dec 18 '10 at 13:18
5

WCF is definitely ready for the real world. Yes sometimes it is overkill so first you have to know if you really need it. If you need WS-* protocol stack or if you need web services interoperability with non MS platform you will need WCF. I'm using WCF regulary and I'm very happy with it.

IMO WCF is third best API MS provided (.NET Core is first, ASP.NET MVC second). It has so many extensibility points that you can do almost anything. But it is not easy. WCF is for mature skilled developers - it's the main WCF drawback.

Reasons mentioned in article are silly. It is like saying that ASP.NET 4.0 is not ready for the real world because sometimes you have to run aspnet_regiis.exe to register .NET 4.0 runtime in IIS or like saying that Lambda expressions are not ready for the real world because you have to learn how to use them.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Not all reasons are silly this one is not silly: After installing WCF in IIS, sometimes it's trowing an exception that refers to the temp directory. To solve this problem you have to re compile the application and re-distribute – user310291 Dec 14 '10 at 22:18
3

Yes, definitely, WCF is ready for real world use, and is being used by lots of large and small corporations around the world.

Yes, hosting in IIS sucks - but that's not WCF's fault, it's IIS which is really just a web server - not an application host.

Therefore, for any serious, production-grade WCF services, I would recommend to always self-host. Skips all the IIS related messiness, gives you full control over your service and your endpoints - all sounding pretty good to me!

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • ...or pay someone to host *you* (and not you + 20k other users on a box :p) –  Dec 19 '10 at 04:02
1

i saw many articles about using WCF for the HPC world , so i guess we have to wait and find out :)

i'm cool with ASMX though

Saif al Harthi
  • 2,948
  • 1
  • 21
  • 26
1

I have done a lot of ranting against WCF lately. It is clunky, heavy and overdone but don't get me wrong it is extremely rich and flexible.

And yes, it is real world ready, already used in thousands of large scale projects.

I have already used it in two projects.

Now, if all you need is lightweight, little-setup HTTP calls, use JSON+HTTP which is in ASP.NET MVC or the new WCF's separate HTTP stack.

Aliostad
  • 80,612
  • 21
  • 160
  • 208
  • Rich and Flexible doesn't mean ready for real world as for me because real world means performance and scalability, easy project life cycle management (aka deployment which seems troublesome). As for large scale what do you mean ? For me it means at least hundreds of millions to billions of hits per year (that's my project's current scale). – user310291 Dec 13 '10 at 23:58
  • **Most** of the scalability is achieved at the architecture and design level not at the technology level. I more or less agree with you but would not knock it straight away. Have a read at my rant here: http://stackoverflow.com/questions/3710635/succinct-and-light-weight-api-restjson-in-net – Aliostad Dec 14 '10 at 00:06
  • Scalability is one thing performance is another. Saying that all depends only on architecture is overexagerated websocket will allow better performance than just http for some kind of real time apps – user310291 Dec 14 '10 at 22:16
1

I skipped wcf.

The main reason is that it causes a LOT of extra code/work and very little benefit over existing mechanisms.

I used to go the asmx route, but I've found those are even too heavy for what we normally need. Also I found that, at least a few years ago, a lot of the java frameworks for dealing with "web services" didn't play nice with some of the advanced things we needed.

Quite frankly doing regular httpwebrequests with posts/gets to an ashx file is dead simple, robust and dynamic. Whereas you will spend a lot of time getting wcf working.

Of course, the only time I ever click the "designer" tab in visual studio is by accident. Maybe I'm a hedonist...or just jaded from all the marketing speak around how these technologies make our apps more "interoperable".

NotMe
  • 87,343
  • 27
  • 171
  • 245
  • 2
    Very little benefit? I guess having services participate in a TransactionScope isn't something everyone needs, but it has great value when you need it. And that is just one feature. – Peter T. LaComb Jr. Dec 14 '10 at 00:00
  • Great idea at least for performance will try this old school stuff :) – user310291 Dec 14 '10 at 00:02
  • 1
    I agree that for web stuff there's not much benefits of using it comparing to the web services. It is more useful when you have other transports (TCP, named pipes, etc). It gives you same programming model for all transports, so you focus on the implementation. – TarasB Dec 14 '10 at 00:02
  • As a side note, the problem I had with java consuming the services was with figuring out the DIME and MTOM binary attachment models. Basically, Biztalk required the soap envelopes to properly validate and the java tools (at the time), well, didn't. We ended up having java call a C# web service (it was more forgiving) which then called Biztalk. PITA but it worked. Hence one of the reasons why we now just use the basics. – NotMe Dec 14 '10 at 15:20
  • @Peter LaComb Jr., @Taras B: Both of your comments are good reasons for going WCF (+1 for both comments); if the app actually needs those items. Of course, if my app needed transactions as part of the web service call I'd probably use Biztalk or Windows Workflow before I went WCF. Also, I don't think I've ever needed to support a different protocol (like named pipes). – NotMe Dec 20 '10 at 14:34
1

There are numerous real-world solutions using WCF for mission-critical functionality in large enterprises all over the world. Just one example I know personally: the e-commerce site of one of the largest retailers of computer games in the UK makes extensive use of WCF services to drive the site and implement order fulfilment. It has millions of customers generating gazillions of hits.

WCF is mainstream. There are no hidden risks, provided (as with any framework) you take the trouble to understand and use it correctly, within a SDLC with good QA processes.

Chris Dickson
  • 11,964
  • 1
  • 39
  • 60
  • Thanks for this example. As for "numerous" I can't see so much advertized. Mission-Critical doesn't mean that it is technically challenging. When I say real world I rather mean High Load users and complex workflow. – user310291 Dec 18 '10 at 13:16
1

WCF is more flexible than webservice. We can use different type of transport protocol according to our requirement. It also consists of modern security model.

Pranjit Kalita
  • 11
  • 1
0

Haven't had any problems deploying WCF projects so far. I'm building a very simple application with it (actually, the application isn't that simple but the Service layer is) and have deployed WCF to three environments (Development, Integration Tests and User Test) without any hassle.

I went with WCF because asmx can't deal with cyclic object graphs, whereas WCF can.

Bruno Brant
  • 8,226
  • 7
  • 45
  • 90
0

We deal with WCF in our projects and for the most part it makes life much simpler in getting services up and running. WCF makes it very simple to hose REST-style services, provides a mechanism for hooking into it's stack to customize how web requests are handled, and allows for separation of the web-specific stuff and your business layer.

ajawad987
  • 4,439
  • 2
  • 28
  • 45