kendo - Telerik Controls con ASP.NET MVC: ¿Esto viola el modelo MVC?

telerik demos

Question

1. ¿El uso de los controles Telerik habilitados con MVC con ASP.NET MVC violará el modelo MVC?

2. Y si no, ¿qué tipo de rendimiento tocó (frente a las características y la velocidad de desarrollo) con el uso de controles Telerik sobre la codificación manual del HTML?

Answer 1

Como yo soy la persona que construyó esa demostración, creo que puedo compartir mi opinión también. Esta aplicación de muestra no viola los principios de MVC según yo. Los RadControls no dependen de ViewState ni de las devoluciones de datos en aplicaciones MVC (puede verificar el resultado generado para verlo usted mismo, no __doPostBack o __VIEWSTATE). De hecho, necesita escribir un código para enlazar la cuadrícula o llenar el menú, pero el código está en la Vista (ASPX) y está completamente relacionado con la presentación (de nuevo, esta es solo mi opinión, así que podría estar equivocado).

También debo mencionar que hay algunas limitaciones: algunas de las funciones incorporadas (que dependen de la devolución de datos) no funcionan en MVC. Sin embargo, trabajará para resolverlos. Siéntase libre de abrir un ticket de soporte o hilo del foro si tiene alguna pregunta particular con respecto a RadControls y ASP.NET MVC.

Answer 2

Estoy bastante seguro de que estos se basan en el modelo PostBack en WebForms y no serían compatibles con las vistas MVC. Probablemente puedas encontrar una forma de que funcionen, pero no estaría de acuerdo con los principios de MVC. Puede mezclar / combinar WebForms con MVC Views en el mismo sitio web si es necesario, pero no lo recomendaría.

Lo que perderá al usar los controles Telerik son la mayoría de los beneficios de MVC: clara separación de preocupaciones, capacidad de prueba mejorada, HTML más simple, una arquitectura más limpia. No me sorprendería descubrir que eventualmente Telerik sale con controles para MVC. Por ahora, consideraría las implementaciones de JavaScript puro para ViewUserControles del lado del cliente o codificadas a mano si necesita reutilizar algunos componentes comunes.

Answer 3

Para su segunda pregunta, con respecto a la puntuación de rendimiento frente a la codificación manual, creo que depende del control que esté utilizando. Por ejemplo, si usa cualquiera de los controles de navegación de Telerik en MVC, como Menú, TabStrip o PanelBar, se ahorrará una TONELADA de codificación manual (ya que un menú / tabstrip / etc requiere mucho del lado del cliente). código para proporcionar las características interactivas (como opciones desplegables) y una gran cantidad de CSS complejos). Por lo tanto, RadControls en MVC ayudará a restaurar la productividad que está acostumbrado a crear aplicaciones ricas de ASPNET.

Para controles más complejos, como la Grilla, que depende mucho de las devoluciones, se beneficia principalmente del estilo proporcionado. Para adaptarse al modelo MVC, los controles como la Grilla requieren bastante codificación "personalizada" para "convertir" eventos de devolución de datos a acciones de URL, por lo que es posible que no guarde una gran cantidad de código en comparación con una plantilla de cuadrícula MVC. Sin embargo, usted ahorrará mucho tiempo en el diseño y la diferencia en el rendimiento debería ser insignificante.

Espero que ayude.

-Todd

Answer 4

Personalmente, no usaría los controles telerik actuales con MVC. Creo que funcionan en algunas situaciones ( http://telerikwatch.com/2009/01/telerik-mvc-demo-app-now-available.html ), pero creo que son bastante similares a viewstate / postback. Sabiendo telerik, saldrán con una versión compatible con MVC, pero parece que tienen mucho trabajo por delante ...

Answer 5

Me doy cuenta de que esta es una vieja pregunta, pero los controles ASP.NET MVC de Telerik son simplemente controles, como datapickers, grids, panelbars, tabstrips. Estos no son rivales del marco MVC. Ellos trabajan en conjunto con eso. Tu pregunta me dice que no entiendes, o al menos no entiendes, qué es realmente MVC.

Para el beneficio de otros que pueden confundirse, MVC significa Modelo-Vista-Controlador . Hay un Modelo , que representa los objetos que está utilizando para almacenar o recuperar valores, una Vista , que muestra esos valores de objetos y se puede usar para configurarlos mediante el uso de controles , como los datapickers de Telerik, las cuadrículas, etc., y el Controlador , que alberga las funciones que representan las vistas e interactúa con los elementos del modelo. Los controles que use para actualizar el modelo deben poder interactuar con ese modelo para cumplir con MVC. Si no lo hicieron, no podrían anunciarse como controles MVC, en primer lugar, entonces sí, sus controles funcionan con, y no "violan", el marco MVC.

Aquí hay uno de esos usos de un control datepicker, junto con un modelo:

VER:

@model MyViewModel

<%= Html.Kendo().DateTimePickerFor(model => model.ExpirationDate)
    .Name("datetimepicker")
    .Value(model.ExpirationDate)        
%>

VIEWMODEL: (o Modelo)

public MyViewModel() {
    public DateTime ExpirationDate { get; set; }
}

CONTROLADOR:

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);
}

Para codificarlos usando las demostraciones de Telerik, es mucho copiar / pegar y varias ediciones pequeñas para su modelo específico y los datos que está ingresando (como se muestra arriba). También hay mucho menos código debido a que los controles tienen casi todo incorporado, por lo que, por supuesto, el tiempo de producción se reduce, hay filtros, paginación y ordenación en cuadrículas que ya están allí. Se enciende añadiendo decir, Filterable() , para filtrar En lugar de tener que crear, digamos, DataColumns individuales y agregarlas a una DataTable, luego vincular eso a una grilla, luego preocuparse por los eventos OnDataBound individuales (que aún podría hacer, pero necesita menos), crear instancias de una grilla, agregar su columnas, establezca las funciones de su controlador para crear, leer, actualizar y eliminar elementos, y establecer las propiedades en la grilla, y habrá terminado:

<%: 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"))
    )
 %>

La "lectura" es tan simple como tomar esas primeras 2 líneas en el public ActionResult Index() anterior y colocarlas en una función public Customers_Read([DataSourceRequest] DataSourceRequest request) {} que devuelve data como .ToDataSourceResult() . La actualización es similar a las últimas 3 líneas en esa función, ya que crea una instancia del modelo, copia los valores del modelo que se transfiere desde la cuadrícula y luego hace algo como dataContext.SaveChanges() para guardar. Una vez guardada, la grilla automáticamente hace otra lectura, por lo que verá los últimos valores. No hay necesidad de ejecutar nada en la devolución de datos para volver a vincular los datos, por lo que no hay más código para escribir.

Solo mire los ejemplos del código aquí para dar una mejor idea: http://demos.telerik.com/aspnet-mvc/