Yesterday I answered a question on
SO related to the problem of consuming an ASP.net webservice from JavaScript on the client-side. So I thought it might be a good idea to put it down in a downloadable example that can be used as a starting point for all those that didn't yet use this method.
What I created is basically a simple example that sends a string to a classic asmx webservice which in turn answers again with a string, which is then displayed on the client-side. A simple greeting service basically :) .
The second example is more complex (although ASP.net makes it really easy to handle) in the sense that I'm sending back a whole object graph: a Person object containing another Location object. For programming such interactions I strongly recommend to use
Firebug. It allows you to inspect the messages that are sent back and forth between the client and server back and you can place breakpoints in your JavaScript, debug it and inspect your variables.
I not going into too much detail now since I don't have the time and moreover I think the example speaks for itself. I just want to mention some important parts regarding the WCF service.
namespace AjaxWebservices.Services
{
[ServiceContract(Namespace = "AjaxWebservices.Services")]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class PersonService
{
...
}
}
If you see such a service definition and you have already worked with the somewhat more traditional asmx services, then you'd call this from your client JavaScript like
function sendToServer(){
AjaxWebservices.Services.PersonService.<method-to-invoke>(<parameters>,onSuccess, onFailure);
}
...
You invoke it with the namespace of the service. But having a WCF service, the namespace definition defined in the ServiceContract (see above) will be the one that actually holds and not the class namespace. In this example above I configured them to have the same name, just for simplicity.
For the rest take a look at the example.
Some of you may also ask why not to use the famous UpdatePanel control. Well, generally you may use it without any problems and have instant Ajax functionality without even modifying a line of code of your traditional app. And that's the point. My personal opinion is just use it for such purposes, i.e. to enhance traditional apps and also in such cases I would be very careful. The major reason is performance. During an asynchronous request to the server, the UpdatePanel will send the whole ViewState of your entire page back to the server. This is needed s.t. on the server-side the whole life-cycle can be completed just as during a normal request. Moreover then the whole rendered HTML will be send back for exchanging it. If you just have a small page, this may not be an issue for you. I had however already experiences, where on a large page an asynchronous paging of a list took on an 56Kbit line about 50-60 seconds, while my optimized, hand-written JavaScript-Webservice solution was able to do it in about 3 - 4 seconds. This is because these requests are encoded in JSON and really small and you don't have the ViewState which can be quite big.
Questions? Thoughts? Hit me up
on Twitter
