asp mvc appropriate ajax usage

I realized that many of my past projects have suff开发者_如何学JAVAered from "too much ajax". I write pretty much all intranet "business" type apps so accessibility to older browser/disabled javascript/etc has never really been much of an issue for me. But things like unable to bookmark/go back/random errors/timeouts that the user doesn't see (I know there are ways around this but just as an example)...and most of all the development time is a lot longer (big issue for me I'm the sole dev) for what seems to be not a whole lot.

From people's experience - when is it appropriate to use ajax in business app/mainly CRUD type sites?

Take this as an example: I have a grid displaying all the registered users. One of the buttons takes you to an edit/details view where you can edit all the info and view further info not displayed on the grid. You can click "save" an ajax request is made and return either a success message or a modelstate with errors converted to JSON and that is displayed in a message above the "save" button (with a bunch of jquery that parses the result) all nice without a page refresh. I have many many screens similar to this. Would it make more sense just to redirect back to the grid displaying all the users once "save" is clicked and successful (with some sort of "flash message" on top stating save was successful) skipping all the ajax/json/etc? As the dev. I have a hard time imaging what would make most sense to the end users, but just doing a redirect would be much simpler and makes sense to me. What are people's experiences in these sort of scenarios?

---

In that scenario I would avoid AJAX all together unless you have a specific reason for it. Partial page updates, keeping a user's place on the page, or other reason.

MVC handles the scenario you describe very well, including the success/failure messages. In this "edit" failure case you'll detect the failure server side and return the same edit view back to the user with model state information. All of their fields will remain populated and you'll easily be able to display validation messages. On the success side you will return your list or index view and possibly use TempData to display a message to the user indicating their successful edit. A little javascript to spice that up and remove the message after 10 seconds or so and the user experience is very good.

This gets even better when you add client side validation, which is much easier in MVC3.

I think you can create a very intuitive experience for the user in this case and avoid ajax/json all together. I do both but I make sure I have a legitimate reason before I start writing client side ajax code.

Take a look at the Steve Sanderson MVC books. He walks through this scenario exactly as you described with good detail. His MVC3 book isn't out yet, and I haven't read the MVC2 book but the original MVC book has it.

http://www.amazon.com/ASP-NET-Framework-Experts-Voice-NET/dp/1430228865/ref=sr_1_4?ie=UTF8&qid=1308745293&sr=8-4

I also like PluralSight online training when I'm looking for fundamental framework guidance like this. http://www.pluralsight-training.net/microsoft/

Of course there are plenty of free blogs and what not that cover MVC too. Have fun.

---

In my application where I have to take a lot of data from the user that happens mostly form main business entities (Employeee, Distributor, etc.) I usually take the route of normal form post rather than ajaxifying the form. Mostly, I use ajax when data to be posted is small and I have to display data on same page after saving.

For instance, on Employees view page you can have a little form to add experiences for the employee and you can save it through ajax and append the entered data back to the same page.

Take the example of Stack Overflow for instance. They use normal form post for saving answers and questions but when it comes to comments where amount of data is small and comments have to be appended on the same page then it makes sense to use ajax in such scenarios.