Best Practice using AJAX with ASP.NET

[HairyMike]

Good Morning,

I would like to open a discussion regarding the best approach to use for creating an AJAX enabled application that operates outside the normal ASP.NET page lifecycle.

In my company, we have deployed an ASP.NET application which makes use of update panels. Some of our clients are in low bandwidth areas and suffer from slow performance, largely because of viewstate. As you know, the entire viewstate is sent back to the server every time you want to do a partial page update and there tends to be a lot of controls on our pages.

We are changing our application model to move away from the ASP.NET page lifecycle and minimise what is sent back to the server. Our application will exist on one single page and load content dynamically using web services or page methods.

This change presents a few challenges;
1) When a user control is dynamically loaded, we also have to load the related javascript/jquery. Ideally, I would like to be able to reference controls on the page the same way we would with inline javascript (i.e var mycontrol = $get('<%=mycontrol.ClientID%>'); ) or something that gives the same functionality.

2) There may be several instances of the control created on the page. Each should maintain its own naming container, prefixing controls accordingly.

3) The controls need to be able to raise and process jquery events.

I've found a really good example here:
http://samuelmueller.com/2008/12/dyn...s-with-jquery/

I have to admit to being somewhat new to jquery, so at the moment a lot of this is over my head.

We have built a rather crude prototype to demonstate the abilities and speed of these techniques to our clients. We have found ourselves creating inline html in the webservices to pass back to our callback functions. Webservices and javascript are registered with the Script Manager. This is very tedious and difficult to maintain, and I am looking for a better way.

Thanks very much for reading. I look forward to hearing some of your experiences and I will write an article when I have a definitive way forward.

Michael

[gep13]

Hey,

That is indeed a very good article, and I think that it covers the topic quite well.

There are a few obvious things that I think need to be cleared up before going to much further.

When you say:

Some of our clients are in low bandwidth areas and suffer from slow performance, largely because of viewstate

Have you gone through the process of removing ViewState from all the controls that don't need it on the page? How many controls do you have on each page? What sort of performance are we talking about here? Is the page taking 5-10 seconds to load? Have you considered breaking the page into smaller pages with discrete operations in each?

To go another route, have you considered the option of implementing your own "viewstate". There are numerous examples of people taking control of this work given the problems with ViewState that ships with ASP.Net.

Gary

[HairyMike]

Hi Gary,

Yes, I'd minimised the amount of viewstate being used over around 50 controls (including composite and standard user controls - forms grids etc) which all did a balley of databinding / hiding and showing - making it nice and ajaxey. Worked fine for us on our average speed network, problem was with the client's upload speed. Their download speed is ok, but 28kb of viewstate could take 10 seconds. I wrote a custom compressor to further reduce the viewstate, but speed improvement was nominal. With webservices / javascript, there is a vast improvement in the speed - almost instant.

Cheers,
Mike

[brin351]

It sounds to me in order to achieve points 1,2,3 you are going to need "state" info passed to your webservice calls because it may be impossible to do it all on the client with JScript and jquery while the webservice has no knowledge of the page state. Hum that's what you where trying to avoid sorry.

[HairyMike]

Hi Brin,

I think I need to just pass some kind of unique id to the webservice so it gives the control a unique name. The page will never need to be reloaded or posted back. The basic idea is that if a control / content is requested, it can be dynamically loaded, and wouldn't have to be reloaded unless a refresh operation starts. The control would stay in the DOM and could be shown or hidden with jquery. It would also be able to start other async calls to webservices through javascript.

Thanks, Michael

[gep13]

Hey,

I can honestly say that I have never had to go down this route, so I am really not sure what to suggest to you for the best.

I am sure once Mendhak gets back from his trip he will have something to suggest.

The page that you have sounds very "busy". Can you give some kind of idea as to what is going on on this page?

Gary

[HairyMike]

Hi Gary,

One example of a page is a complete system to track sales opportunities. We have a gridview list with filtering / searching options, a form for creating new items, and another panel opens for reviewing the sales opportunity detailing history with an update form. There are quite a few extenders from the ajax control tool kit.

Thanks, Mike

[brin351]

Because your going down a kind of pure ajax path which has little to do with asp web forms and infact is intererring with the system have you considered changing to MVC which will give complete control over what's rendered to the client. I have only played with MVC but it sounds like a prime candidate. I googled mvc, ajax, jquery and lots is being discussed.

[gep13]

Hey,

The other suggestion, whether good or bad, I will leave to you to decide, would be the use of Silverlight.

Is this something that you have considered?

Gary

[HairyMike]

Hi Gary,

Yes we do have silverlight in our sights. I have looked into RIA services, and this does actually look quite powerful. I plan to get myself and other team members through a ms certified course on silverlight later in the year.

Thanks

[gep13]

Hey,

Sounds like a plan.

It just feels like you are re-inventing a lot of code, that could be done in another technology, so maybe worth investigating.

Gary

[HairyMike]

At the moment, we are pressing ahead using webservices (registered with a scriptmanager) called through javascript. Inline html on the server created by the webservices then rendered in some div. We have some JQuery stuff in use, albeit doing pretty simple stuff (i.e hiding and showing divs).

In the immediate future, I will continue investigating MVC (I found what looks like a good clientside MVC). It does look like it will solve our inline html mess. Ultimately we will create a silverlight UI, but we cannot be assured that all of our clients will have the plugin.

Best Regards

[gep13]

Hey,

That is a good point. It is not a major installation, but it might cause some problems depending on the client.

Will be interesting to hear how you get on with all this, pitfalls, etc.

Gary

[HairyMike]

I found this link that I feel lays out all the issues very well. We have setup a single page interface. Hard work, some hacks needed to make everything work. Will start using MVC soon.

http://msdn.microsoft.com/en-us/magazine/cc507641.aspx

[gep13]

Will start using MVC soon.

I think I am going to be starting to use it soon as well.

Gary