JQuery / JSON + .Net Service Layer - to WCF or Not to WCF?

Question

I Recently had a discussion with a colleague of mine about the pros / cons of WCF. He mentioned about how much code is generated to support WCF, and also the overhead required. It was mentioned that a simple jQuery /Ajax post to a .aspx page (or a handler for that matter) that returns JSON would work more efficiently and takes much less code to implement. I am also aware of the new WCF Web API and feel that technology may solve the "bloated"-ness required in attaining a proxy etc... by just outputting JSON.

So when developing a relational DB (MSSQL) storage model, with a fairly complex Business Layer (C#) and Data Access Layer (EntityFW).. what's a good technology for creating a "service layer" which will spit out View Models represented in JSON, with a CQRS(Command Query..) approach in mind.. The app would use the service layer to support it's required UI, as well as provide an available subset of services (outputting JSON data) for service subscribers..

In other words an admin panel to support the admin UI, and service endpoints that return JSON to access the configurations made from the administration UI.

What are some potential technologies to use as the transport / communication layer. I'd like to use a pure RESTful approach, but am not against doing some URL rewriting with IIS.

Obviously some of the available technologies are: WCF
WCF Web API (should this even be separate?)
Straight request / response (query string to .aspx / handler)
Would using MVC .Net solve this entire problem? maybe their single page app approach?

any suggestions / feedback from developing this type of application?

Thanks,

Answer 1

If you are on frontline .Net (4.5), I see two options really:

• Web API (the mvc controller REST thing)
• Wcf via SOAP

Both of these could act as a service layer in a .Net system.

You could also use Wcf over JSON (REST), but this is not a simple thing to implement and maintain.

Wcf have a high learning curve, but once you pass it, Wcf really becomes simple for most usages, especially if you are containing your client proxy creation meaningfully.

Answer 2

I hesitate to offer this up as an answer, since it's not exactly objective. But my personal experience is that every time I have been involved in a project that used WCF, we regretted it.

If you are implementing something that genuinely makes use of WCF's flexibility (e.g. a SOA that needs to be accessed via HTTP/SOAP over the web and also via TCP over an intranet), then by all means, go with WCF. But if you're doing something which can be implemented in another way - and something as simple as handlers to return JSON responses to AJAX queries certainly can - I would not choose WCF. There is just way too much complexity in there that you will not have any need for, but will all provide opportunities for problems.

Answer 3

In answer to the 1st part of your question, I agree with your colleague's assessment that outputting JSON would be much more efficient & simple to do. (KISS principle)

Before you go ahead with WCF though, I highly recommend that you consider the excellent Service Stack - an opensource .NET & Mono REST web services framework.

The performance is excellent (as evidenced by the supporting benchmarks) and the developer experience (for me personally) is much better than working with WCF.

Answer 4

Your colleague needs to understand what WCF is. Once everything is setup correctly, WCF can be very powerful. We built a RESTful service recently on top of WCF and we very happy with the result.

Here is the Microsoft's definition of WCF:

Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments.

Few things WCF does better than a standard ASP.NET page (or service):

Service development

In an ASP.NET you must wire everything yourself. With WCF you add few attributes such as [ServiceContact] and [OperationContract]. Once you did that you can associate an address and a binding with a service type.

They include BasicHttpBinding (supporting the WS-BasicProfile 1.1 and Basic Security Profile 1.0), WSHttpBinding, WSDualHttpBinding, WSFederationBinding, NetTcpBinding, NetNamedPipeBinding, NetMsmqBinding, MsmqIntegrationBinding & NetPeerTcpBinding. All you have to do is to change the configuration. WCF does the rest.

Hosting

Your ASP.NET page or webservice is typically hosted in a website in IIS. WCF allows you to host your service in ISS but also as a standalone application or any compatible host. Again, without having to change anything but the configuration.

Message representation

WCF provides you with much richer feature including how you add header in the messages.

<service name="Service ">
 <endpoint 
  address="EchoService"
  binding="basicHttpBinding"
  contract="IEchoService ">
  <headers>
  <dsig:X509Certificate 
   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
   ...
  </dsig:X509Certificate>
  </headers>
 </endpoint>

... and a lot more

WCF will also help you with:

• Data Representation
• Service Description
• Exception Handling
• State Management
• Globalization
• and of course, one of it's main feature, Security.

I think the best you can do right now is test yourself. You can be amazed or disgusted. But in any case, you'll know if WCF is for you or not.

Further reading: Comparing ASP.NET Web Services to WCF Based on Development

Answer 5

Well, I've decided not to use WCF, if an alternative could be found. Here are the reasons:

1. Hard to develop (learning curve guys, basic to medium developers)
2. Messy configuration (all those bindings, endpoints, etc.)
3. Client knows about data types of the server (contract attributes)
4. SOAP is not as handy as JSON (readability for developers)
5. SOAP is MUCH more verbose than JSON
6. Unfriendly URLs, which can't be called directly from the browser (SOAP envelopes)
7. WctTestClient sucks, because it doesn't have a simple alphabetical sort for functions
8. You gotta suffer to make it RESTful
9. Your models are not POCO, because of [DataContract], [DataMember], etc. attributes
10. No method overloading (which some consider to be a form of polymorphism)

I personally have the experience of working with WCF in two mid-sized projects, and in both of them I wish I could be the decision-maker so that I could decide to use something else.