Telerik contrôles avec ASP.NET MVC: Est-ce le modèle MVC viole?

StackOverflow https://stackoverflow.com/questions/510059

  •  21-08-2019
  •  | 
  •  

Question

  1. MVC activé contrôles Telerik avec ASP.NET MVC le modèle MVC violent?

  2. Et sinon, quel genre de performances a frappé (par rapport à des caractéristiques et de la vitesse de développement) qu'il y aura à l'utilisation Telerik contrôles exercés sur la main coder le HTML?

Était-ce utile?

La solution

Depuis que je suis la personne qui a construit cette démo, je pense que je peux partager mon opinion aussi bien. Cet exemple d'application ne viole pas les principes MVC selon moi. RadControls ne reposent pas sur ViewState ou postbacks dans les applications MVC (vous pouvez vérifier la sortie générée pour voir par vous-même - pas __doPostBack ou __VIEWSTATE). En effet, vous devez écrire un code pour lier la grille ou remplir le menu - mais le code est dans la vue (ASPX) et est entièrement lié à la présentation (encore une fois c'est juste mon avis, donc je peux me tromper)

Je dois aussi mentionner qu'il ya des limites en effet - quelques-unes des fonctionnalités intégrées (qui reposent sur postback) ne fonctionnent pas dans MVC. Cependant travaillera à les résoudre. Ne hésitez pas à ouvrir un ticket de support ou d'un fil de forum si vous avez des questions particulières en ce qui concerne RadControls et ASP.NET MVC.

Autres conseils

Pour votre deuxième question, en ce qui concerne la performance par rapport à succès de codage manuel, je pense que cela dépend de la commande que vous utilisez. Par exemple, si vous utilisez des commandes de navigation Telerik dans MVC- tels que le menu, TabStrip, ou PanelBar- vous vous enregistrez une TONNE de codage manuel (depuis un menu / tabstrip / etc. Nécessite beaucoup de côté client code pour fournir les fonctions interactives (comme déroulantes options) et beaucoup de CSS complexe). Ainsi, les RadControls dans MVC contribuera à rétablir la - la productivité -. Vous êtes habitué lors de la construction des applications riches ASPNET

Pour les contrôles plus complexes, comme la grille, qui dépendent beaucoup de postbacks, vous bénéficiant principalement du style fourni. Pour adapter le modèle MVC, les contrôles comme la grille ont besoin d'un peu de « coutume » de codage à « convertir » les événements postback à l'URL des actions, de sorte que vous ne pouvez pas gagner beaucoup de code par rapport à un modèle de grille MVC. Vous -Will- économiser beaucoup de temps sur le style, cependant, et la différence de performance devrait être negligble.

L'espoir qui aide.

-Todd

Je suis assez sûr que ceux-ci se fondent sur le modèle postback dans WebForms et ne seraient pas compatibles avec des vues MVC. Vous pouvez probablement trouver un moyen pour eux de travailler, mais il ne serait pas conforme aux principes MVC. Vous pouvez mélanger / WebForms match avec vue MVC dans le même site Web si nécessaire, mais je ne le recommanderais pas.

Qu'est-ce que vous perdrez en utilisant les contrôles Telerik sont la plupart des avantages de MVC: séparation claire des préoccupations, améliorer la testabilité, plus maigre HTML, une architecture plus propre. Il ne me surprendrait pas de constater que finalement Telerik sort avec des commandes pour MVC. Pour l'instant, je regarde soit pures implémentations Javascript pour côté client ou ViewUserControls code à la main si vous avez besoin de réutiliser certains composants communs.

Personnellement, je ne voudrais pas utiliser les contrôles Telerik actuels avec MVC. Je pense que ( http: // telerikwatch.com/2009/01/telerik-mvc-demo-app-now-available.html ), mais je pense qu'ils sont tout à fait viewstate / postback centrée. Sachant telerik, ils sortiront avec une version compatible MVC, mais semble comme ils ont beaucoup de travail devant eux ...

Je sais que c'est une vieille question, mais Telerik de contrôles ASP.NET MVC sont simplement contrôle, comme datepickers, grilles, panelbars, tabstrips. Ceux-ci ne sont pas en rival du MVC Cadre . Ils travaillent en conjonction il. Votre question me dit que vous ne le faites pas, ou tout au moins ne non, comprendre ce que MVC est vraiment.

Pour le bénéfice des autres qui peuvent être confondus, ainsi, MVC signifie Model-View-Controller . Il y a un Modèle , qui représente les objets que vous utilisez pour le stockage ou la récupération des valeurs, Voir , qui affiche les valeurs d'objet et peut être utilisé pour les définir par l'utilisation de < em> contrôles , comme les datepickers de Telerik, grilles, et autres, et le contrôleur , qui abrite les fonctions qui rendent les vues et interagit avec les éléments du modèle. Les commandes que vous utilisez pour mettre à jour le modèle doit être en mesure d'interagir avec ce modèle pour être MVC conforme. Si elles ne l'ont pas, ils ne pouvaient pas être annoncés comme contrôles MVC, en premier lieu, alors oui, leurs contrôles fonctionnent avec, et ne pas « violer », le framework MVC.

Voici une telle utilisation d'un contrôle DatePicker, conjointement avec un modèle:

VIEW: 

@model MyViewModel

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

viewmodel: (ou modèle) 

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

CONTRÔLEUR: 

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

Pour les coder en utilisant des démos de Telerik, il est beaucoup de copier / coller et diverses petites modifications pour votre modèle spécifique et les données que vous entrez (comme indiqué ci-dessus). Il y a aussi beaucoup moins de code en raison des contrôles ont presque tout intégré, donc du temps de production de cours est coupé en bas, des choses comme le filtrage, la pagination, le tri dans grilles est déjà là - vous l'activez simplement en ajoutant par exemple, Filterable(), pour le filtrage. Au lieu d'avoir à créer, par exemple, DataColumns individuels et les ajouter à un DataTable, puis lier cela à une grille, puis vous soucier de chaque événement (OnDataBound que vous pouvez encore faire, mais il faut moins), vous instancier une grille, ajouter vos colonnes, définissez vos fonctions de contrôleur pour la création, la lecture, la mise à jour et la suppression d'éléments, et définir des propriétés sur la grille, et vous avez terminé: 

<%: 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 « lecture » est aussi simple que de prendre les 2 premières lignes dans le public ActionResult Index() ci-dessus et de les mettre dans une fonction qui retourne public Customers_Read([DataSourceRequest] DataSourceRequest request) {} comme data .ToDataSourceResult(). La mise à jour est semblable aux 3 dernières lignes dans cette fonction, puisque vous instancier le modèle, copiez les valeurs du modèle qui est passé depuis la grille, puis faire quelque chose pour sauver comme dataContext.SaveChanges(). Une fois enregistré, la grille fait automatiquement une autre lecture, il verra les dernières valeurs. Pas besoin de quoi que ce soit d'autre à courir sur postback pour les données rebind, donc pas plus de code à écrire.

Il suffit de regarder les exemples de code ici pour donner une meilleure idée: http: //demos.telerik. com / aspnet-mvc /

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top