Telerik Controls with ASP.NET MVC: Does this violate the MVC model? - asp.net-mvc

Question

Will using MVC enabled Telerik controls with
ASP.NET MVC violate the MVC model?
And if not, what kind of performance
hit (versus features and development speed) will there be with using
Telerik controls over manually
coding the HTML?

Answer 1

Since I am the person who built that demo I think I can share my opinion as well. This sample application does not violate the MVC principles according to me. RadControls do not rely on ViewState or postbacks in MVC applications (you can check the generated output to see for yourself - no __doPostBack or __VIEWSTATE). Indeed you need to write some code to bind the grid or populate the menu - but still the code is in the View (ASPX) and is entirely related with the presentation (again this is just my opinion so I might be wrong).
I should also mention that there are some limitations indeed - some of the built-in features (that rely on postback) do not work in MVC. However will work on resolving them. Feel free to open a support ticket or forum thread should you have any particular questions with regards to RadControls and ASP.NET MVC.

Answer 2

To your second question, regarding performance hit vs. manual coding, I think it depends on the control you're using. For example, if you use any of the Telerik navigation controls in MVC- such as Menu, TabStrip, or PanelBar- you'll save yourself a TON of manual coding (since a menu/tabstrip/etc. requires a lot of client-side code to provide the interactive features (like drop down options) and a lot of complex CSS). So, the RadControls in MVC will help restore the -productivity- you're used to when building rich ASPNET apps.
For more complex controls, like the Grid, which depend a lot on postbacks, you're mainly benefitting from the provided styling. To fit the MVC model, controls like the Grid require quite a bit of "custom" coding to "convert" postback events to URL actions, so you may not save a lot of code vs. a MVC grid template. You -will- save a lot of time on styling, though, and the performance difference should be negligble.
Hope that helps.
-Todd

Answer 3

I'm pretty sure that these rely on the PostBack model in WebForms and wouldn't be compatible with MVC views. You could probably find a way for them to work, but it wouldn't be in keeping with the MVC principles. You can mix/match WebForms with MVC Views in the same web site if needed, but I wouldn't recommend it.
What you will lose by using the Telerik controls are most of the benefits of MVC: clear separation of concerns, enhanced testability, leaner HTML, a cleaner architecture. It wouldn't surprise me to find that eventually Telerik comes out with controls for MVC. For now, I'd look at either pure Javascript implementations for client-side or hand-coded ViewUserControls if you need to reuse some common components.

Answer 4

Personally, I wouldn't use the current telerik controls with MVC. I think they work in some situations (http://telerikwatch.com/2009/01/telerik-mvc-demo-app-now-available.html), but I think they are quite viewstate / postback centric. Knowing telerik, they will come out with a MVC compatible version, but looks like they have a lot of work in front of them...

Answer 5

I realize this is an old question, but Telerik's ASP.NET MVC controls are simply controls, like datepickers, grids, panelbars, tabstrips. These are not in rival to the MVC framework. They work in conjunction with it. Your question tells me you do not, or at least did not, understand what MVC really is.
For the benefit of others that may be confused, as well, MVC stands for Model-View-Controller. There's a Model, that represents objects you are using for storage or retrieval of values, a View, that displays those object values and can be used to set them through use of controls, such as Telerik's datepickers, grids, and such, and the Controller, that houses the functions that render the views and interacts with the model elements. The controls you use for updating the model must be able to interact with that model to be MVC-compliant. If they did not, they could not be advertised as MVC controls, in the first place, so yes, their controls work with, and do not "violate", the MVC framework.
Here is one such use of a datepicker control, in conjunction with a model:
VIEW:
#model MyViewModel
<%= Html.Kendo().DateTimePickerFor(model => model.ExpirationDate)
.Name("datetimepicker")
.Value(model.ExpirationDate)
%>
VIEWMODEL: (or Model)
public MyViewModel() {
public DateTime ExpirationDate { get; set; }
}
CONTROLLER:
public ActionResult Index(int id)
{
var data = dataContext.SomeTable.Where(e => e.ID == id).FirstOrDefault();
// return View(data); // this would allow you to use #model SomeTable
// in your view, and not require a ViewModel, but returns the whole
// record for the given ID
// ViewModels allow you flexibility in what you return
MyViewModel mvm = new MyViewModel();
mvm.ExpirationDate = data.ExpirationDate;
return View(mvm);
}
For coding them using Telerik's demos, it is a lot of copy/paste and various small edits for your specific model and data you are entering (as shown above). There is also far less code because of the controls have most everything built-in, so of course production time is cut way down, things like filtering, paging, sorting in grids is already there - you turn it on just by adding say, Filterable(), for filtering. Instead of having to create, say, individual DataColumns and add them to a DataTable, then bind that to a grid, then worry about individual OnDataBound events (which you could still do, but need less of), you instantiate a grid, add your columns, set your controller functions for creating, reading, updating, and deleting items, and set any properties on the grid, and you are done:
<%: Html.Kendo().Grid<Models.ViewModels.MyViewModel>()
.Name("grid")
.Columns(columns =>
{
columns.Bound(c => c.ExpirationDate).Format("MM/DD/YYYY");
})
.HtmlAttributes(new { style = "height: 380px;" })
.Scrollable()
.Sortable()
.Filterable()
.Pageable(pageable => pageable
.Refresh(true)
.PageSizes(true)
.ButtonCount(5))
.DataSource(dataSource => dataSource
.Ajax()
.Read(read => read.Action("Customers_Read", "Grid"))
.Create(create => create.Action("Customers_Create", "Grid"))
.Update(update=> update.Action("Customers_Update", "Grid"))
.Delete(delete => create.Action("Customers_Delete", "Grid"))
)
%>
The "read" is as simple as taking those first 2 lines in the public ActionResult Index() above and putting them into a public Customers_Read([DataSourceRequest] DataSourceRequest request) {} function that returns data as .ToDataSourceResult(). Updating is similar to the last 3 lines in that function, since you instantiate the model, copy the values from the model that is passed in from the grid, then do something like dataContext.SaveChanges() to save. Once saved, the grid automatically does another read, so it will see the latest values. No need for anything else to run on postback to rebind the data, so no more code to write.
Just look at the code examples here to give a better idea: http://demos.telerik.com/aspnet-mvc/