Is there an advantage to using WCF to facilitate AJAX calls ?

Question

I am currently reading through a proposal, where this person is proposing to use WCF services to facilitate AJAX calls in a web application. They say that WCF can serialize data more efficiently. I personally have never considered going this approach. I have always liked calling MVC controllers using jQuery's AJAX functionality, and that has never been a problem.

Now there is this proposal to use WCF for AJAX, and i'm a little sceptical. I would like to keep and open mind. To me it seems to add another layer, unnecessarily complicating things. Is this worth it?

Answer 1

+1 I'm a little sceptical too. I don't think the average punter sends large amounts of data across Ajax/jQuery and if they are I think they need to refactor a little.

So if that is the case then what possible gain could you get from using WCF over normal mvc functionality when you are serializing (maybe) 2 or 3 k of data. I think even 2k is a lot to be sending via Ajax.

Using WCF in the code behind would be a good idea but for ajax serilization, dunno about that one.

Answer 2

WCF has its own serializer, which (IIRC) is binary, and which handles object graphs that XML serialization can't. It also shouldn't have the verbose overhead of XML. As griegs noted, that's probably an excessive concern with optimization.

Is WCF more efficient than JSON? Don't know, not sure it matters that much.

In coding, there would be a thin service layer, and the ASP.NET hosting, so that adds overhead. Whether it affects performance is a separate issue; it's just overhead that's visible, as compared to .asmx or MVC controller overhead for handling services.

I don't think you really gain any of WCF's other capabilities in this case. Using WCF for ASP.NET hosted web services restricts you to a specific binding protocol.

EDIT: Looking at the project where I used WCF for web servces, it is web HttpBinding. As noted in comments, that would be JSON. On the other hand, if you're using the ASP.NET ScriptManager tag, it builds a proxy dynamically that includes parsing the data, so you're really never aware of how the data is serialized.

Answer 3

It'd be worth it if you're exposing the same services over additional endpoints with different bindings, but if you're just using AJAX then I'd go with an MVC controller that returns JsonResult. You can still get parameter serialization using action filters.

Unless there's specific required functionality that only WCF provides thenan MVC controller will be simpler. You won't have to worry about contracts, bindings, configuration, WCF's JSON formatting, etc.

Answer 4

As a side note, ASP.Net MVC currently uses the JavaScriptSerializer (even though it has been marked as obsolete post .Net 3.5) for serializing JSON data where WCF uses the DataContractJsonSerializer.

So in terms of JSON serialization efficiency, MVC will be more efficient as the JavaScriptSerializer is alot more lightweight (all be it quick and dirty) than the DataContractJsonSerializer.

HTH

Answer 5

It sound interesting in concept, but at the end of the day won't you still be returning Json? Maybe I'm missing something, but how can the Json being returned by WCF be more optimized than the Json being returned by WCF? It's like saying my XML is more optimized than yours? It's not like WCF can return binary data to the browser - you would have no way of using that data... (Or can it??) I suppose the WCF serializer could possibly be faster than the MVC one, but the bottleneck is always going to be getting this data across the wire.

Of course this is all pure speculation - we would need the proposal you read to give an accurate opinion. And it depends very much on how much data you're sending via Ajax.

Answer 6

I wouldn't bother with a another layer, especially not WCF, to facilitate AJAX calls. If you're already using MVC, the JsonResult will do fine (and according to Jason Fox above, more efficient).

Unless you need a web service for operations that require a web service (i.e. interacting across the web) why bother? An MVC Controller has always done the job for me without the annoying overhead.