Il s'agit du deuxième article d'une série sur DotVVM.
Le premier article était plus probablement une enquête. J'ai essayé avec un exemple simple de montrer comment travailler dans DotVVM à un niveau de base. L'article, en fait, n'a pas abordé le plus important: comment cela fonctionne.
Cet article est consacré à ce problème ainsi qu'à l'optimisation du trafic.
Cet article examinera plus en détail la communication entre le client et le serveur.
Vous pouvez prendre un exemple d'un article précédent avec une liste de tâches. Dans la demande écrite, il était possible d'ajouter de nouveaux cas et de les marquer comme terminés.
La communication
Lorsqu'une page est demandée, l'URL est analysée et DotVVM la recherche dans DotVVMStartup.cs, où dans la table de routage il y a un chemin vers le fichier .dothtml, où, à son tour, il y a une directive sur le ViewModel.
Le ViewModel est sérialisé en json et cela impose certaines règles au ViewModel. Toutes les méthodes et propriétés publiques (chaîne, Guid, bool, int, autres types numériques, DateTime, collections (tableau, List) tombent dans json. Dans le cas de List, il peut s'agir d'une collection des mêmes types simples ou d'objets que ces types utilisent .
Lorsque vous travaillez avec DotVVM dans des projets réels, plusieurs règles pour l'architecture ViewModel ont été révélées, que nous essayons d'adhérer.
- N'utilisez pas Entity Framework DbContext directement dans ViewModel
- N'affichez pas les entités propres dans la vue, mais utilisez les DTO (Data Transfer Objects)
- Pour plus de contrôle sur le ViewModel, il doit hériter de DotvvmViewModelBase
Supposons donc que ViewModel a été correctement assemblé dans json, toutes les liaisons frontales ont été générées dans View et la page chargée. Alternativement, les méthodes héritées de DotvvmViewModelBase ont passé: Init (), Load () et PreRender (). Lorsque vous chargez la page pour la première fois, le remplacement de ces fonctions peut être utile, mais tout d'abord.
Ajoutez un nouveau cas avec une liste.
- AJAX POST est envoyé au serveur depuis json du ViewModel modifié
- Le même ViewModel est déchargé dans la mémoire du serveur, mais inchangé
- Par Init ()
- Le serveur ViewModel inchangé est comparé à ce qui provenait du client
- Produit par Load ()
- La méthode elle-même est en cours d'exécution.
- Par PreRender ()
- Après comparaison, les modifications sont renvoyées au client.
Lorsque votre ViewModel hérite de DotvvmViewModelBase, vous avez accès à Init (), Load () et PreRender (). Les trois méthodes sont abstraites et peuvent être étendues et modifiées.
En outre, dans DotvvmViewModelBase, il existe une propriété du contexte de contexte de demande, d'où il y a accès à l'objet de demande, à la propriété IsPostBack, aux paramètres d'URL et
bien plus encore .
L'envoi avec chaque postback du ViewModel entier n'est pas très efficace. Afin de réduire au moins en quelque sorte la quantité de données envoyées, dans DotVVM, il existe plusieurs approches.
Attribut Bind
L'attribut Bind vous permet d'indiquer au compilateur comment gérer les propriétés dans le ViewModel.
- [Lier (Direction.Both)] - Le paramètre par défaut. Des données sont envoyées à chaque demande.
- [Bind (Direction.None)] - Il est principalement utilisé pour les services et les façades qui ne subissent pas de sérialisation, mais sont utilisés dans ViewModel pour charger ou enregistrer cela.
- [Bind (Direction.ServerToClient)] - Les données ne sont envoyées que dans une seule direction, du serveur au client. Cela signifie uniquement lors du chargement de la page, mais pas avec la publication.
- [Bind (Direction.ServerToClientFirstRequest)] - Idéal pour les données statiques. Par exemple, les options dans une zone de liste déroulante
- [Bind (Direction.ClientToServer)] - Les données sont envoyées dans un seul sens, avec publication, du client vers le serveur.
Commandes statiques
DotVVM vous permet également de demander une méthode statique sur le serveur. L'efficacité de ces méthodes est qu'elles n'envoient que la réponse, c'est-à-dire que le ViewModel entier provient du serveur, mais seulement la partie dont nous avons besoin. Ces méthodes statiques peuvent prendre des paramètres et renvoyer des valeurs.
Dans notre exemple, il y a un endroit où vous pouvez appliquer des commandes statiques. Lorsque nous marquons un cas comme terminé. Il n'est pas nécessaire d'envoyer l'intégralité du ViewModel au serveur.
Vous pouvez réécrire la méthode MarkAsDone (ToDoItem item) dans la méthode statique en la transférant dans une classe statique distincte et en ajoutant l'attribut
[AllowStaticCommand] à la méthode.
namespace FirstDotvvmApp { public static class ToDoItemValidator { [AllowStaticCommand] public static bool IsDone() => true; } }
Vous devez également modifier la vue en ajoutant une directive avec l'espace de noms où se trouve notre classe statique.
@import FirstDotvvmApp
Le bouton utilisera non seulement la commande, mais staticCommand.
<dot:Button Validation.Enabled="false" Visible="{value: !IsDone}" Text="Mark as done" Click="{staticCommand: IsDone = ToDoItemValidator.IsDone()}"> </dot:Button>
À titre de comparaison, vous pouvez voir combien de trafic nous avons économisé.
Habituellement, une combinaison des deux approches est utilisée pour économiser du trafic lors de la communication sur des projets réels.
Les références
Vous trouverez plus d'exemples sur l'utilisation de nouvelles fonctionnalités
ici .
Récemment, il y avait aussi un
flux (Eng.) Sur DotVVM 2.0 , où ils ont parlé des principales innovations et nouvelles fonctionnalités.