Dies ist der zweite Artikel in einer Reihe über DotVVM.
Der erste Artikel war eher eine Tatsachenfeststellung. Ich habe versucht, anhand eines einfachen Beispiels zu zeigen, wie man in DotVVM auf einer grundlegenden Ebene arbeitet. Der Artikel ging in der Tat nicht auf das Wichtigste ein: wie es funktioniert.
Dieser Artikel widmet sich diesem Problem sowie der Verkehrsoptimierung.
In diesem Artikel wird die Kommunikation zwischen Client und Server genauer untersucht.
Sie können ein Beispiel aus einem vorherigen Artikel mit einer Aufgabenliste übernehmen. In der dort verfassten Bewerbung konnten neue Fälle hinzugefügt und als erledigt markiert werden.
Kommunikation
Wenn eine Seite angefordert wird, wird die URL analysiert und DotVVM sucht sie in DotVVMStartup.cs, wo in der Routentabelle ein Pfad zur DOTHTML-Datei vorhanden ist, in der sich wiederum eine Direktive im ViewModel befindet.
Das ViewModel ist in json serialisiert, wodurch dem ViewModel bestimmte Regeln auferlegt werden. Alle öffentlichen Methoden und öffentlichen Eigenschaften (Zeichenfolge, Guid, Bool, Int, andere numerische Typen, DateTime, Sammlungen (Array, Liste) fallen in json. Im Fall von Liste kann es sich um eine Sammlung derselben einfachen Typen oder Objekte handeln, die diese Typen verwenden .
Bei der Arbeit mit DotVVM in realen Projekten wurden verschiedene Regeln für die ViewModel-Architektur offenbart, die wir einhalten möchten.
- Verwenden Sie Entity Framework DbContext nicht direkt in ViewModel
- Zeigen Sie keine sauberen Entitäten in der Ansicht an, sondern verwenden Sie DTO (Data Transfer Objects).
- Für mehr Kontrolle über das ViewModel sollte es DotvvmViewModelBase erben
Angenommen, ViewModel wurde erfolgreich in json zusammengestellt, alle Front-End-Bindungen wurden in View generiert und die Seite geladen. Alternativ haben die von DotvvmViewModelBase geerbten Methoden übergeben: Init (), Load () und PreRender (). Wenn Sie die Seite zum ersten Mal laden, kann das Überschreiben dieser Funktionen hilfreich sein, aber das Wichtigste zuerst.
Fügen Sie einen neuen Fall mit einer Liste hinzu.
- AJAX POST wird von json des geänderten ViewModel an den Server gesendet
- Das gleiche ViewModel wird in den Serverspeicher entladen, jedoch unverändert
- Mit Init ()
- Das unveränderte Server-ViewModel wird mit dem vom Client stammenden Server verglichen
- Produziert von Load ()
- Die Methode selbst wird ausgeführt.
- Von PreRender ()
- Nach dem Vergleich werden die Änderungen an den Client zurückgesendet.
Wenn Ihr ViewModel DotvvmViewModelBase erbt, haben Sie Zugriff auf Init (), Load () und PreRender (). Alle drei Methoden sind abstrakt und können erweitert und geändert werden.
Auch in DotvvmViewModelBase gibt es eine Eigenschaft des Anforderungskontextes Context, von der aus Zugriff auf das Anforderungsobjekt, auf die IsPostBack-Eigenschaft, auf URL-Parameter und
vieles mehr besteht .
Das Senden mit jedem Postback des gesamten ViewModel ist nicht sehr effizient. Um die gesendete Datenmenge zumindest irgendwie zu reduzieren, gibt es in DotVVM verschiedene Ansätze.
Attribut binden
Mit dem Bind-Attribut können Sie dem Compiler mitteilen, wie mit Eigenschaften im ViewModel umgegangen werden soll.
- [Bind (Direction.Both)] - Die Standardeinstellung. Daten werden bei jeder Anfrage gesendet.
- [Bind (Direction.None)] - Es wird hauptsächlich für Dienste und Fassaden verwendet, die keiner Serialisierung unterzogen werden, aber in ViewModel zum Laden oder Speichern verwendet werden.
- [Bind (Direction.ServerToClient)] - Daten werden nur in einer Richtung vom Server zum Client gesendet. Dies bedeutet nur beim Laden der Seite, nicht jedoch beim Postback.
- [Bind (Direction.ServerToClientFirstRequest)] - Ideal für statische Daten. Zum Beispiel Optionen in einem Kombinationsfeld
- [Bind (Direction.ClientToServer)] - Daten werden nur in einer Richtung mit Postback vom Client zum Server gesendet.
Statische Befehle
Mit DotVVM können Sie auch eine statische Methode auf dem Server anfordern. Die Effektivität solcher Methoden besteht darin, dass sie nur die Antwort senden, dh das gesamte ViewModel kommt vom Server, aber nur den Teil, den wir benötigen. Solche statischen Methoden können Parameter annehmen und Werte zurückgeben.
In unserem Beispiel gibt es einen Ort, an dem Sie statische Befehle anwenden können. Wenn wir einen Fall als erledigt markieren. Es ist nicht erforderlich, das gesamte ViewModel an den Server zu senden.
Sie können die MarkAsDone-Methode (ToDoItem-Element) in die statische Methode umschreiben, indem Sie sie in eine separate statische Klasse übertragen und der Methode das Attribut
[AllowStaticCommand] hinzufügen.
namespace FirstDotvvmApp { public static class ToDoItemValidator { [AllowStaticCommand] public static bool IsDone() => true; } }
Sie müssen die Ansicht auch ändern, indem Sie eine Direktive mit dem Namespace hinzufügen, in dem sich unsere statische Klasse befindet.
@import FirstDotvvmApp
Die Schaltfläche verwendet nicht nur den Befehl, sondern auch staticCommand.
<dot:Button Validation.Enabled="false" Visible="{value: !IsDone}" Text="Mark as done" Click="{staticCommand: IsDone = ToDoItemValidator.IsDone()}"> </dot:Button>
Zum Vergleich können Sie sehen, wie viel Verkehr wir gespart haben.
Normalerweise wird eine Kombination beider Ansätze verwendet, um Datenverkehr bei der Kommunikation mit realen Projekten zu sparen.
Referenzen
Weitere Beispiele zur Verwendung neuer Funktionen finden Sie
hier .
Ebenfalls kürzlich gab es einen
Stream (Eng.) Auf DotVVM 2.0 , in dem über die wichtigsten Innovationen und neuen Funktionen gesprochen wurde.