[SOLAR] Padronização das consultas secundárias na tela de detalhes do processo
Spike
Este estudo tem como finalidade apresentar os tipos de consultas secundárias que estão sendo realizadas na tela de detalhes do processo no SOLAR e com esse levantamento, mostrar qual é a mais viável de manter no sistema.
Introdução
A área de processos é uma das mais importantes dentro do SOLAR. O processo em si é composto por um conjunto grande de informações e para melhor mostrar esses dados para o usuário foi pensado em criar uma tela responsável por mostrar os detalhes do processo. A questão é que para trazer todos esses detalhes é preciso fazer mais de uma consulta na base de dados. Com isso existem três formas de buscar dados de forma secundário dentro do sistema, sendo elas: Consulta por AJAX; Consulta por Partial View; Consulta por ViewComponent.
Utilizando essas formas de consulta na tela de detalhes do processo temos dificuldade na manutenção do código já que temos sempre que levar em consideração se vamos ter que alterar as três maneiras de consultas e manter elas.
Historia e complexidade estimada
História | Complexidade em pontos |
Padronizar consultas secundárias na tela de detalhes do processo | 8 |
AJAX (Javascript Assíncrono e XML)
Ajax é um conjunto de tecnologias, resumindo-se em conhecer bem javascript, manipulação de DOM, CSS e XML.
Vantagens:
- Requisições assíncronas que não causam o recarregamento da página;
- Tratamento de dados e a formatação da exibição fica por conta do script que foi carregado inicialmente quando se acessou a página;
Partial View (Exibição Parcial)
Partial View é um arquivo de marcação Razor sem uma diretiva @page que torna a saída HTML dentro da saída renderizada de outro arquivo de marcação .cshtml
Vantagens:
- Desacoplar arquivos de marcação grandes em componentes menores;
- Redução de código idêntico, com regras de lógica ou não, em diversos arquivos;
ViewComponent (Componente de Exibição)
ViewComponent é similar a uma Partial View, porém mais poderosa pois não depende de uma model, apenas dos dados de onde ela é chamada.
Vantagens:
-TípicamenteTipicamente invocada por uma página de layout;
- Pode ser invocada de forma assíncrona;
- Aceita lógica de negócio na sua chamada;
Ajax pode ser uma boa ideia por ser um conjunto de tecnologias para diminuir a carga imposta ao backend, deixando a cargo do javascript que fica do lado do cliente, trabalhar com o carregamento das páginas e a consulta dos dados em segundo plano. Porém é apenas uma boa ideia quando não estamos trabalhando com DotNet. O ecossistema da Microsoft tem seus próprios meios de realizar esse tipo de atividade mantendo a semântica do padrão MVC.
Então podemos entender que Partial View é uma melhor opção comparada com o AJAX, contudo o cenário apresentado é a página de detalhes do processo dentro do SOLAR, esse cenário é dinâmico, contendo regras de negócio específicas para cada parte que compõe os dados do processo a serem exibidos. Poderíamos trabalhar com essas regras específicas que temos no sistema, mas ainda existe um problema que é a dependência da Partial View com a Model. A consulta principal ainda seria um linq enorme com muitos Includes para que cada parte seja passada como Model às pequenas partes que montariam a página final para o usuário.
Com isso, podemos usar a própria documentação, disponibilizada pela Microsoft, relacionada a ViewComponent onde diz que ela 'é similar a uma Partial View, porém mais poderosa pois não depende de uma model'. Isso porque a ViewComponent deriva de uma classe que compartilha do mesmo nome ViewComponent que tem como um de seus retornos uma View com sua Model.
Se é uma consulta mais enxuta, somente com o necessário para ser obtido enquanto os demais dados são consultados de forma separada e semântica, então a consulta por ViewComponent é a melhor opção, no momento, para nosso sanar nosso problema.
Valor Agregado
Esse não é um estudo que terá um valor agregado para o cliente final, pois na execução de suas tarefas dentro do SOLAR ele não ira notar diferença brusca ao acessar os detalhes de um processo. Por outro lado, para os desenvolvedores que mantem esse sistema e para os futuros que iram contribuir com ele verão que as consultas secundárias tem um padrão a ser seguido, além de terem incerteza menor ao pontuar U.S. relacionadas aos detalhes do processo já que com essa solução a flexibilidade de efetuar uma refatoração no código se torna algo mais entendível de manusear.
Conclusão
Com a explicação de como é a situação atual ao acessar os detalhes de um processo no SOLAR foi levantado um conjunto de maneiras de se fazer uma consulta secundária. Após esse levantamento, foi apontando os pontos fortes de cada maneira e foi visto qual era mais viável para o problema apresentado.
Time de desenvolvimento: Turing |
Anderson Anschau |
João Vitor Paulino Nobre |
Milton Daniel Yama |
Paulo Indre Barbosa Ferreira Santos |
Elaborado em 12 de julho de 2022.