Este es el segundo artículo de una serie sobre DotVVM.
El primer artículo fue más probablemente un hallazgo de hechos. Intenté con un ejemplo simple mostrar cómo trabajar en DotVVM a un nivel básico. El artículo, de hecho, no tocó lo más importante: cómo funciona.
Este artículo está dedicado a este problema, así como a la optimización del tráfico.
Este artículo examinará con más detalle la comunicación entre el cliente y el servidor.
Puede tomar un ejemplo de un artículo anterior con una lista de tareas pendientes. En la aplicación escrita allí, fue posible agregar nuevos casos y marcarlos como hechos.
Comunicación
Cuando se solicita una página, la URL se analiza y DotVVM la busca en DotVVMStartup.cs, donde en la tabla de ruta hay una ruta al archivo .dothtml, donde, a su vez, hay una directiva en ViewModel.
ViewModel se serializa en json y esto impone ciertas reglas en ViewModel. Todos los métodos públicos y propiedades públicas (string, Guid, bool, int, otros tipos numéricos, DateTime, colecciones (array, List) caen en json. En el caso de List, puede ser una colección de los mismos tipos simples u objetos que estos tipos usan .
Al trabajar con DotVVM en proyectos reales, se revelaron varias reglas para la arquitectura ViewModel, a las que intentamos adherirnos.
- No utilice Entity Framework DbContext directamente en ViewModel
- No muestre entidades limpias en la vista, pero use DTO (objetos de transferencia de datos)
- Para tener más control sobre ViewModel, debe heredar DotvvmViewModelBase
Supongamos que ViewModel se ensambló correctamente en json, todos los enlaces de front-end se generaron en View y se cargó la página. Alternativamente, los métodos heredados de DotvvmViewModelBase pasaron: Init (), Load () y PreRender (). Cuando carga la página por primera vez, la anulación de estas funciones puede ser útil, pero lo primero es lo primero.
Agregue un nuevo caso con una lista.
- AJAX POST se envía al servidor desde json del ViewModel modificado
- El mismo ViewModel se descarga en la memoria del servidor, pero no cambia
- Por Init ()
- El servidor sin cambios ViewModel se compara con lo que vino del cliente
- Producido por Load ()
- El método en sí mismo se está ejecutando.
- Por PreRender ()
- Después de la comparación, los cambios se envían de vuelta al cliente.
Cuando su ViewModel hereda DotvvmViewModelBase, tiene acceso a Init (), Load () y PreRender (). Los tres métodos son abstractos y pueden ampliarse y modificarse.
Además, en DotvvmViewModelBase hay una propiedad del contexto del contexto de solicitud, desde donde hay acceso al objeto de solicitud, a la propiedad IsPostBack, a los parámetros de URL y
mucho más .
Enviar con cada devolución de datos todo el ViewModel no es muy eficiente. Para reducir al menos de alguna manera la cantidad de datos enviados, en DotVVM hay varios enfoques.
Atributo de enlace
El atributo Bind le permite decirle al compilador cómo manejar las propiedades en ViewModel.
- [Bind (Direction.Both)] : la configuración predeterminada. Los datos se envían en cada solicitud.
- [Bind (Direction.None)] : se utiliza principalmente para servicios y fachadas que no se someten a serialización, pero se usan en ViewModel para cargar o guardar esto.
- [Bind (Direction.ServerToClient)] : los datos se envían solo en una dirección, del servidor al cliente. Significa solo cuando se carga la página, pero no con devolución de datos.
- [Bind (Direction.ServerToClientFirstRequest)] - Ideal para datos estáticos. Por ejemplo, opciones en un cuadro combinado
- [Bind (Direction.ClientToServer)] : los datos se envían solo en una dirección, con devolución de datos, desde el cliente al servidor.
Comandos estáticos
DotVVM también le permite solicitar un método estático en el servidor. La efectividad de tales métodos es que solo envían la respuesta, es decir, todo el ViewModel proviene del servidor, pero solo la parte que necesitamos. Tales métodos estáticos pueden tomar parámetros y devolver valores.
En nuestro ejemplo, hay un lugar donde puede aplicar comandos estáticos. Cuando marcamos un caso como hecho. No es necesario enviar el ViewModel completo al servidor.
Puede reescribir el método MarkAsDone (elemento ToDoItem) al estático transfiriéndolo a una clase estática separada y agregando el atributo
[AllowStaticCommand] al método.
namespace FirstDotvvmApp { public static class ToDoItemValidator { [AllowStaticCommand] public static bool IsDone() => true; } }
También debe cambiar la Vista agregando una directiva con el espacio de nombres donde se encuentra nuestra clase estática.
@import FirstDotvvmApp
El botón usará no solo el comando, sino el staticCommand.
<dot:Button Validation.Enabled="false" Visible="{value: !IsDone}" Text="Mark as done" Click="{staticCommand: IsDone = ToDoItemValidator.IsDone()}"> </dot:Button>
A modo de comparación, puede ver cuánto tráfico hemos ahorrado.
Por lo general, se utiliza una combinación de ambos enfoques para ahorrar tráfico al comunicarse en proyectos reales.
Referencias
Más ejemplos sobre el uso de nuevas características se pueden encontrar
aquí .
También recientemente hubo una
transmisión (Eng.) En DotVVM 2.0 , donde hablaron sobre las principales innovaciones y nuevas características.