Develop Reference

Use of AJAX in C# .NET MVP web application

I know this is a general question - however I want to gain a little advice before investing a lot of time looking into something that may not be suitable.
I have a C# .NET MVP web application, it needs to complete a new complex/heavy query when a user logs in (to find new messages for a user), however needs to do so without impacting performance. I have looked into multi threading in the past, however it would still need to wait until the new query completes, and adds a lot of complexity into the solution (we do not use multi threading currently).
I am wondering if Ajax would be a solution, so once the screen loads, is it possible to kick off an ajax command after page load that would execute and refresh part of the screen with the results?
How does the application handle if the user navigates to different screen? (note I planned to add the ajax component to master/base page which is part of every screen).
Would appreciate feedback, if people think its a possible approach I would do a proof of concept to prove it out.

If it doesn't need to return result to client side you can use HostingEnvironment.QueueBackgroundWorkItem to start the task then return it to client straight away.
If the query needs to return the result to client side then you need a to use Ajax call from client to server then update the view with data returned. You may want have a look at the client side framework such as angularJS.

What is the best practice when updating a progress bar?

I am currently working on a project in ASP.NET MVC 4 and came along a module where a progress bar is needed. The question I am having right now is "What is the best way to implement an async progress bar?".
After some lookup I came across the following method:
Create a startEvent() and getProgress() in C# code.
Use javascript setTimeout() to call the getProgress() method asynchronously.
(Example: https://www.devexpress.com/Support/Center/Example/Details/E4244)
My remark with this method is that that causes the code to be dependent on the timeout you choose. So it would take some fiddling to find the best and most performant timeout.
Now the method that I would most likely have used before I researched the matter is the following:
In code behind, create a method handleItem(int index) which takes an index and does everything you want to do with the item at that index.
Determine the number of items you want to handle and pass that to your javascript.
In javascript, initiate a for loop that loops from 0 to the amount - 1, and for each index, it initiates an ajax-call to handleItem(i).
On that ajax-call's complete-statement, you can update the progress bar with the new amount.
My questions here are the following:
Does this expose too much of the program logic?
Does this create too much overhead seeing as every call goes to the server and back?
Are there any other reasons why I should refrain from using this method?
Thanks in advance
Koen Morren

This is not a recommended strategy, because the client drives the process. If there is any discontinuation of connectivity or maybe the user closes the browser, the process will stop.
Generally, if you use straight HTTP you will need to poll (aka pull) from javascript. The pseudo code is pretty much this:
Call Creates Task ID and sends it to client
Client queries the status of task with given ID
Another possibility are WebSockets, which allow your client to listen for changes that are pushed by the server.
There are many options to store the progress of a given state. You can index the progress by the HttpContext, task id, or some user id, or even store it in a database and use SqlDependency to get notifications of when the status is changed.
In summary, polling has more lag than push mechanisms. Clients should not drive an asynchronous process, but they should be either notified or provided some mechanisms on the status of an async process.

Unlike ASP.NET, there is few way to push data from server to client in MVC, WebSockets or SingnalR like api(s) can work for you.
The ajax approach is good and give you reliable mechanism to update data no matter user go to other page or closes the browser, every time ajax launched it will update UI. So there is nothing wrong there just have a fair interval in javascript.
Does this expose too much of the program logic?
Code will be written only in class file to calculate current %age.
2.Does this create too much overhead seeing as every call goes to the server and back?
No, ajax are light-weight calls
3.Are there any other reasons why I should refrain from using this method?
This method will allow user to freely navigate to other resources as ajax will work independently.

Pass Info to Client without Page Refresh in Asp.net MVC Application

Today we have seen some sites that pass data or notification to client without page refresh. Named Real time or interactive applications.
some of known site are :
Stackoverflow : notifications
Freelancer : passes project and professional counts asynchronously in numeric format
Google Mail : Counts mail memory usage by users in total.
and so more ... .
I have tried and searched some tools like SignalR. Basically SignalR designed for creating chat application. But is there a direct way without any extension in Microsoft Technologies to meet our purpose? For example suppose we want a simple counter like freelancer, Have we no way except using extensions like SignalR?

You can look at a technique called polling (which SignalR falls back to when support for other methods are not present), basically the concept is that every x seconds you'd send a request to the server to check for an update (more or less), for example (using jQuery):
setInterval(function() {
$.get("/Messages/GetCount", function(data) {
// do something with the data ...
});
}, 30000);
Every 30 seconds, check the Messages count - and perform an action accordingly. Here is a good article on polling and long polling (it mentions a SignalR alternative called Socket.IO).
Having said all that, I'd seriously just go with SignalR, those guys tested all kinds of corner cases, performance etc.

Use a Javascript timer on the client-side to make periodic asynchronous requests for updated information. This updated information can then be used to update the client-side, or can be used to prompt further requests for more details.
This solution can work for situations where you do not need to receive immediate updates whenever there are updates available on the server side (but instead can wait for the timer interval). It also may present some scaling issues and can lead to wasting bandwidth and client/server time while making unnecessary calls.
To overcome either of these, it would be best to use a library like SignalR (which can do much more than just chat applications - check out this blog post for a real world implementation that has nothing to do with chat).

Use Microsoft's ASP.NET Ajax implementation or JQuery:
Microsoft Ajax Overview

Server Side code Pushing Data to client Browser while current thread is busy Comet (programming)

I am writing one simple web page with bunch of textboxes and a button control. Now when user finished editing the values on this text boxes user has to click the button and this button invoke heavily process intensive algorithm on server side code based on the data received from client (Textboxes)
And it could some time takes up to 30 to 45 minutes to complete the whole operation so the current thread is still inside the button click event handler function.
That background task only provides one event, and the web page subscribes to it to get some text data after each stage of processing
I was wandering if there is any way I can keep user up-to-date with what is the current progress on that background task. I have div element to print the current status information
So I am looking for some sort of reverse mechanism then "get" and "post".
I have read some articles on the Comet (programming) but I can't find any easy or definitive answer
Thanks in advance

Perhaps the simplest way is to submit the job, and get an id back via a straightforward page POST. That id corresponds to the long running job on the server side.
The returned page can then automatically refresh via the HTTP meta refresh mechanism, and the server can return status etc. in the refreshed page. The page will continually refresh with the id every (say) 30s until the job is complete.
It's a brute-force mechanism, but it's straightforward. Plus it has the advantage of allowing the user to bookmark the page and go away/come back. Given that your job is running for 30/45 mins, that could be important.

You are on the right track with 'Comet' (aka Ajax-Push or reverse-Ajax) - Comet is essentially an umbrella term for the ability for the server to 'push' something back to the client without the client triggering the event. Some Ajax frameworks are starting to build this in, and it is not something i would suggest trying to implement yourself close to the metal, because there are a lot of different things to consider (different webapp servers, threading models, etc). You can see that StackOverflow has some of this functionality, when it notifies you of a new answer coming in if you are writing one yourself for a given question.
Now all that being said, in your case, given the length of time of the server side processing, I would agree with Brian's answer that you should give the running job an id and use a more simple refresh mechanism to check it. If you wanted to add the look and feel of a server side push, you could query the server via standard ajax on an interval to check if the job is done rather than a simple refresh, and change the page when it is done through that Ajax call. If your job is able to report progress, then standard ajax could refresh your div with that progress, and there is no need for a server side push.

I agree completely with Brian Agnew's suggestion, with one possible improvement. Since you're essentially doing server-push operations, it might be worth considering a comet server. Now, I say that with a caveat - if you're really only managing jobs that complete every 30-45 minutes, then it may well be overkill. However, it has the advantage that you can push the results to the user when they've completed, and if the user is not longer connected, you can do something different (such as send them a notification email).

It depends:
If you need to be instantly notified when the process ends Comet (long polling) is for you
If some delay is acceptable (for instance the system notifies you 1 minute after the process finishes) then AJAX timers (polling) is your you.
Take a look to three examples of both techniques based on ItsNat framework:
Comet
AJAX Timers
Asynchronous Tasks (similar to
Comet, one shot)
I'm sorry, is Java

Building a scalable ASP.NET MVC Web Application

I'm currently in the process of building an ASP.NET MVC web application in c#.
I want to make sure that this application is built so that it can scale out in the future without the need for major re-factoring.
I'm quite keen on using some sort of queue to post any writes to my database base to and have a process which polls that queue asynchronously to perform the update. Once this data has been posted back to the database the client then needs to be updated with the new information. The implication here being that the process to write the data back to the database could take a short while based on business rules executing on the server.
My question is what would be the best way to handle the update from the client\browser perspective.
I'm thinking along the lines of posting the data back to the server and adding it to the queue and immediately sending a response to the client then polling at some frequency to get the updated data. Any best practices or patterns on this would be appreciated.
Also in terms of reading data from the database would you suggest using any particular techniques or would reading straight from db be sufficient given my scenario.
Update
Thought I'd post an update on this as it's been a while. We've actually ended up using Windows Azure but the solution is applicable to other platforms.
What we've ended up doing is using the Windows Azure Queue to post messages\commands to. This is a very quick process and returns immediately. We then have a worker role which processes these messages on another thread. This allows us to minimize any db writes\updates on the web role in theory allowing us to scale more easily.
We handle informing the user via emails or even silently depending on the type of data we are dealing with.

Not sure if this helps but why dont you have an auto refresh on the page every 30 seconds for example. This is sometimes how news feeds work on sports websites, saying the page will be updated every x minutes.
<meta http-equiv="refresh" content="120;url=index.aspx">

Why not let the user manually poll the status of the request? This is how your typical e-commerce app is implemented. When you purchase something online, the order is submitted to a queue for fullfillment. After it's submitted, the user is presented with a "Thank you for your order" page and a link where they can check the status of the order. The user can visit the link anytime to check the status, no need for an auto-poll mechanism.
Is your scenario so different from this?

Sorry in my previous answer I might have misunderstood. I was talking of a "queue" as something stored in a SQL DB, but it seems on reading your post again you are may be talking about a separate message queueing component like MSMQ or JMS?
I would never put a message queue in the front end, between a user and backend SQL DB. Queues are good for scaling across time, which is suitable between backend components, where variances in processing times are acceptable (e.g. order fulfillment)... when dealing with users, this variance is usually not acceptable.

While I don't know if I agree with the logic of why, I do know that something like jQuery is going to make your life a LOT easier. I would suggest making a RESTful web API that your client-side code consumes. For example, you want to post a new order to the system and have the client responsive? Make a post to www.mystore.com/order/create and have that return the new URI to access the order (i.e. order#) as a URI (www.mystore.com/order/1234). That response is then stored in the client code and a jQuery call is setup to poll for a response or stop polling on an error.
For further reading check out this Wikipedia article on the concept of REST.
Additionally you might consider the Reactive Extensions for .NET and within that check out the RxJS sub-project which has some pretty slick ways of handling with the polling problem without causing you to write the polling code yourself. Fun things to play with!

Maybe you can add a "pending transactions" area to the UI. When you queue a transaction, add it to the user's "pending transactions" list.
When it completes, show that in the user's "pending transactions" list the next time they request a new page.
You can make a completed transaction stay listed until the user clicks on it, or for a predetermined length of time.