Este é o segundo artigo de uma série sobre o DotVVM.
O primeiro artigo foi mais provável que um fato. Tentei com um exemplo simples mostrar como trabalhar no DotVVM em um nível básico. O artigo, de fato, não abordou o mais importante: como funciona.
Este artigo é dedicado a esse problema, além da otimização do tráfego.
Este artigo examinará mais detalhadamente a comunicação entre o cliente e o servidor.
Você pode dar um exemplo de um artigo anterior com uma lista de tarefas. No aplicativo escrito lá, foi possível adicionar novos casos e marcá-los como concluídos.
Comunicação
Quando uma página é solicitada, a URL é analisada e o DotVVM a procura no DotVVMStartup.cs, onde na tabela de rotas existe um caminho para o arquivo .dothtml, onde, por sua vez, existe uma diretiva no ViewModel.
O ViewModel é serializado em json e isso impõe certas regras no ViewModel. Todos os métodos públicos e propriedades públicas (string, Guid, bool, int, outros tipos numéricos, DateTime, coleções (matriz, Lista) se enquadram em json.No caso de List, pode ser uma coleção dos mesmos tipos simples ou objetos que esses tipos usam .
Ao trabalhar com o DotVVM em projetos reais, várias regras para a arquitetura do ViewModel foram reveladas, às quais tentamos aderir.
- Não use o Entity Framework DbContext diretamente no ViewModel
- Não mostre entidades limpas na exibição, mas use DTO (objetos de transferência de dados)
- Para obter mais controle sobre o ViewModel, ele deve herdar o DotvvmViewModelBase
Portanto, suponha que o ViewModel tenha sido montado com êxito no json, todas as ligações de front-end foram geradas no View e a página carregada. Como alternativa, os métodos herdados de DotvvmViewModelBase passaram: Init (), Load () e PreRender (). Quando você carrega a página pela primeira vez, a substituição dessas funções pode ser útil, mas primeiro as primeiras coisas.
Adicione um novo caso com uma lista.
- O AJAX POST é enviado ao servidor a partir do json do ViewModel modificado
- O mesmo ViewModel é descarregado na memória do servidor, mas inalterado
- Por Init ()
- O servidor inalterado ViewModel é comparado ao que veio do cliente
- Produzido por Load ()
- O próprio método está sendo executado.
- Por PreRender ()
- Após a comparação, as alterações são enviadas de volta ao cliente.
Quando seu ViewModel herda DotvvmViewModelBase, você tem acesso a Init (), Load () e PreRender (). Todos os três métodos são abstratos e podem ser estendidos e modificados.
Também no DotvvmViewModelBase há uma propriedade do contexto de solicitação Context, de onde há acesso ao objeto de solicitação, à propriedade IsPostBack, aos parâmetros de URL e
muito mais .
O envio a cada postback de todo o ViewModel não é muito eficiente. Para, pelo menos de alguma forma, reduzir a quantidade de dados enviados, no DotVVM existem várias abordagens.
Atributo de ligação
O atributo Bind permite que você informe ao compilador como manipular propriedades no ViewModel.
- [Vincular (Direction.Both)] - A configuração padrão. Os dados são enviados em cada solicitação.
- [Vincular (Direction.None)] - É usado principalmente para serviços e fachadas que não sofrem serialização, mas são usados no ViewModel para carregar ou salvar isso.
- [Bind (Direction.ServerToClient)] - Os dados são enviados apenas em uma direção, do servidor para o cliente. Significa apenas ao carregar a página, mas não com postagem.
- [Bind (Direction.ServerToClientFirstRequest)] - Ideal para dados estáticos. Por exemplo, opções em uma caixa de combinação
- [Bind (Direction.ClientToServer)] - Os dados são enviados apenas em uma direção, com postagem, do cliente para o servidor.
Comandos estáticos
O DotVVM também permite solicitar um método estático no servidor. A eficácia de tais métodos é que eles enviam apenas a resposta, ou seja, todo o ViewModel vem do servidor, mas apenas a parte de que precisamos. Tais métodos estáticos podem receber parâmetros e retornar valores.
No nosso exemplo, há um lugar onde você pode aplicar comandos estáticos. Quando marcamos um caso como concluído. Não é necessário enviar o ViewModel inteiro para o servidor.
Você pode reescrever o método MarkAsDone (item de ToDoItem) no método estático, transferindo-o para uma classe estática separada e adicionando o atributo
[AllowStaticCommand] ao método.
namespace FirstDotvvmApp { public static class ToDoItemValidator { [AllowStaticCommand] public static bool IsDone() => true; } }
Você também deve alterar a Visualização adicionando uma diretiva ao espaço para nome em que nossa classe estática está localizada.
@import FirstDotvvmApp
O botão usará não apenas o comando, mas o staticCommand.
<dot:Button Validation.Enabled="false" Visible="{value: !IsDone}" Text="Mark as done" Click="{staticCommand: IsDone = ToDoItemValidator.IsDone()}"> </dot:Button>
Para comparação, você pode ver quanto tráfego economizamos.
Geralmente, uma combinação de ambas as abordagens é usada para economizar tráfego ao se comunicar em projetos reais.
Referências
Mais exemplos sobre o uso de novos recursos podem ser encontrados
aqui .
Também recentemente, houve um
fluxo (Eng.) No DotVVM 2.0 , onde eles conversaram sobre as principais inovações e novos recursos.