This is the second article in the DotVVM series.
The first article was more informational. I tried on a simple example to show how to work in DotVVM at a basic level. The article, in fact, did not affect the most important: how it works.
This article as well as traffic optimization is devoted to this article.
In this article we will take a closer look at the communication between the client and the server.
You can take an example from the previous article with a list of cases. In the application written there, you could add new cases and mark them as done.
Communication
When a page is requested, the URL is parsed and DotVVM searches for it in DotVVMStartup.cs, where in the route table there is a path to the .dothtml file, where, in turn, there is a directive on ViewModel.
ViewModel is being serialized in json and this imposes certain rules on the ViewModel. All public methods and public properties (string, Guid, bool, int, other numeric types, DateTime, collections (array, List) fall into json. In the case of List, it can be a collection of the same simple types or objects that these types use .
When working with DotVVM in real projects, several rules for the ViewModel architecture emerged, which we are trying to follow.
- Do not use Entity Framework DbContext directly in ViewModel
- Do not show pure Entity in View, but use DTO (Data Transfer Objects)
- For more control over the ViewModel, it must inherit DotvvmViewModelBase
So, imagine that the ViewModel was successfully assembled in json, all the front-end bindings were generated in the View and the page was loaded. Alternately passed the methods inherited from DotvvmViewModelBase: Init (), Load () and PreRender (). When you first load the page, override these functions may be useful, but first things first.
Let's add a new thing to the list.
- AJAX POST is sent to the server from the json of the modified ViewModel
- The same ViewModel is unloaded into the server's memory, but not changed.
- Produced by Init ()
- Unchanged server ViewModel is compared with what came from the client
- Produced by Load ()
- The method itself is executed.
- Produced by PreRender ()
- After comparing, changes are sent back to the client.
When your ViewModel inherits DotvvmViewModelBase you have access to Init (), Load () and PreRender (). All three methods are abstract and can be expanded and modified.
Also in DotvvmViewModelBase there is a Context context property of the request, from which there is access to the request object, the IsPostBack property, and URL parameters a
lot more .
It is not very efficient to send the entire ViewModel with each postback. In order to somehow reduce the amount of data being sent, there are several approaches in DotVVM.
Bind attribute
The Bind attribute allows the compiler to tell how to handle properties in the ViewModel.
- [Bind (Direction.Both)] - The default setting. Data is sent with each request.
- [Bind (Direction.None)] - Mainly used for services and facade that do not undergo serialization, but used in ViewModel for loading or saving this.
- [Bind (Direction.ServerToClient)] - Data is sent only in one direction, from the server to the client. It means only when loading the page, but not when postbacking.
- [Bind (Direction.ServerToClientFirstRequest)] - Ideal for static data. For example options in the combo box
- [Bind (Direction.ClientToServer)] - Data is sent only in one direction, upon postback, from client to server.
Static commands
DotVVM also allows you to make a request for a static method on the server. The effectiveness of such methods is that they send only an answer, that is, the entire ViewModel comes from the server, and only the part we need. Such static methods can take parameters and return values.
In our example there is a place where you can apply Static commands. When we mark a deal as “done.” It is not necessary to send the entire ViewModel to the server.
You can rewrite the MarkAsDone method (ToDoItem item) to a static one by transferring it to a separate static class and adding the
[AllowStaticCommand] attribute to the method.
namespace FirstDotvvmApp { public static class ToDoItemValidator { [AllowStaticCommand] public static bool IsDone() => true; } }
You also need to change the View by adding a directive with the namespace where our static class is located.
@import FirstDotvvmApp
The button will use not just command, but staticCommand.
<dot:Button Validation.Enabled="false" Visible="{value: !IsDone}" Text="Mark as done" Click="{staticCommand: IsDone = ToDoItemValidator.IsDone()}"> </dot:Button>
For comparison, you can see how much we saved traffic.
Usually a combination of both approaches is used to save traffic when communicating on real projects.
Links
More examples on using new features can be found
here .
Also recently passed
stream (eng.) On DotVVM 2.0 , where they told about the main innovations and new features.