I have been asked to investigate the possibility of re-engineering an existing ASP.NET AJAX Web Application as under MVC.
The project, as it stands ATM, is very heavily relient on Telerik’s ASP.NET AJAX controls.
I’ve yet to have to opportunity to interview the person responsible for this request, so I’m unsure of the drivers for this, but I believe that as well as looking for a more structured solution (the original was developed in a very organic way) I believe that one of the goals is to also get a lot of the code running client-side and to use a structured form for the development there also.
So, My question is, is there a defined set of considerations for something like this? Or, if people do this kind of thing at all, do they just wing it?
The main driver for doing anything using AJAX is to make the user experience better.
This is mainly done by having controls updated without page reloads.
This is a design choice.
I believe the Telerik AJAX controls can be used in MVC with a bit of extra work, but Telerik also has specific MVC controls.
So you could buy and use those (or similar from other vendors). These may not however map 1 to 1 with all the features you need.
Another option is a half way house, an MVC app can also contain .aspx pages, so you migrate your app slowly, with maybe some of the original pages brought in without changing them to MVC.
2
Whilst I don’t know much about Ajax controls (I am currently working on an intranet based MVC application), I would advise the use of Razor markup if you are looking to implement a lot of client-side code.
Basic Introduction to Razor here
Depending on your development environment too, in my (admittedly limited) experience Razor has proven to be incredibly useful and easy to use.
The link above justifies the use of Razor itself better than I could, so I will let it do the talking. Suffice it to say Razor led to an easier life creating Views in MVC.
0
When we started the migration of our project to a more MVC-oriented style, we were also using Telerik Ajax. We wanted the project to be shippable during the migration, so we first refactored the code to fit the MVC pattern, then switched the framework.
The pattern switch was implemented by relying heavily on WebMethod to populate our views, replacing the ASP.NET and Telerik components with pure HTML and Javascript, and completely stop relying on ViewState.
You then just need to modify the Views, and the rest should mostly fit.
1