Israel Aece

Software Developer

Lazy Loading e Contextos de Domínio

Quando optamos por desenvolver uma aplicação orientada ao domínio (DDD), uma série de termos e conceitos devem ser entendidos para que sejam bem aproveitados e consigamos assim expressar em nosso código o que for necessário para atender a demanda daquela aplicação, serviço ou funcionalidade. O principal guia que agrupa todos esses termos é o livro do Eric Evans, chamado de Domain-Driven Design: Tackling Complexity in the Heart of Software.

Para persistência geralmente utilizamos repositórios (também descrito neste livro), que recorremos para inserir novos dados ou até mesmo para extrair os registros existentes, e mais tarde, persistir as eventuais alterações realizadas durante o processamento de alguma tarefa. E na maioria das implementações de repositórios, por trás (infraestrutura), sempre há um ORM que faz toda a mágica.

Na medida em que vamos desenvolvendo nosso domínio, vamos agregando às entidades diversas características e funcionalidades, tornando a classe cada vez mais próxima ao mundo real. E, como sabemos, os ORMs fornecem a possibilidade de habilitarmos um recurso chamado de lazy loading. Apenas para recordar, ele posterga a extração dos dados até que a mesma seja demandada, o que em outras palavras significa que a consulta será encaminhada à base de dados somente quando acessarmos a propriedade onde estão o(s) dado(s) custoso(s). É comumente relacionado à coleções, mas há situações onde se refere à outras classes ou até mesmo propriedades (como um array de bytes). Abaixo alguns exemplos (em negrito) do que poderia ser considerado como lazy loading:

public class Duplicata
{
    public AnaliseConfirmativa Confirmacao { get; private set; }

    public string Numero { get; private set; }

    public Sacado Sacado { get; }

    public IEnumerable<AcaoDeCobranca> AcoesDeCobranca
    {
        get
        {
            return acoesDeCobranca;
        }
    }

}

Com pouca configuração, os ORMs permitem postergar a carga das informações somente quando elas são solicitadas. Abaixo um pseudo-código que ilustra os vários momentos que vamos recorrer ao banco de dados; repare que somente quando acessamos as propriedades negritadas é que elas são extraídas, tornando um processo transparente para quem escreve o código.

var duplicata = repositorioDeTitulos.BuscarPorId(1);
//SELECT Numero, Sacado FROM Duplicata WHERE TituloId = 1

Console.WriteLine(duplicata.Confirmacao.Data);
//SELECT Data, Status, Confirmador FROM AnaliseConfirmativa WHERE Id = 3

foreach (var acao in duplicata.AcoesDeCobranca)
    //SELECT * FROM AcoesDeCobranca WHERE TituloId = 1
{
    //...
}

Como já era de se esperar, o ORM honra a configuração de lazy loading, e recorre ao banco somente quando de fato precisamos dos dados. Mas vamos detalhar melhor o que acontece no código acima: primeiramente recorremos ao repositório para extrair a duplicata de identificador 1. A consulta que foi feita devolve apenas os dados básicos da duplicata (número e sacado), e é tudo o que queremos até então. Logo que precisamos da parte da confirmação, uma nova consulta é feita. Por fim, quando queremos iterar pelas ações de cobrança, uma terceira consulta é feita para extrair os registros filhos.

Podemos perceber que as "partes" da duplicata são carregadas sob demanda, mas como disse anteriormente, em certos contextos, poderíamos poupar trabalho e já carregar juntamente com os dados básicos, os dados complementares para executar uma determinada ação. Vamos supor que tivéssemos dois ambientes: confirmação e cobrança. No primeiro ambiente, gostaria de que em uma única consulta me retornasse os dados inerentes ao processo de confirmação da duplicata; já no segundo ambiente, gostaria que as ações de cobrança também fossem extraídas tão logo quando a classe Duplicata fosse materializada.

Mas a configuração do ORM é única, não me permitindo customizar isso caso a caso, ambiente por ambiente. Se a performance é um ponto crucial da aplicação, é capaz de termos que começar a poluir a interface do repositório com métodos que retorne - ainda - a duplicata, mas que contextualizem para qual ambiente queremos:

var duplicata = repositorioDeTitulos.BuscarDuplicataParaConfirmacao(1);
var duplicata = repositorioDeTitulos.BuscarDuplicataParaCobranca(1);

E no interior de cada um dos métodos, recorreríamos a API do ORM para fazer a carga antecipada das informações relativas aquele contexto. Apesar de funcionar, em pouco tempo, é provável que o repositório comece a ter diversos métodos que estão ali mais para tentar "burlar" o ORM/sistema, e induzi-los a extrair os dados necessários para executar a operação desejada pelo usuário dentro daquele contexto.

Note que com um pequeno exemplo é possível ver o tamanho do problema que podemos ter ao criar um grande domínio e sem nos preocuparmos com a separação em contextos. Eles precisam ser bem pensados para tentar mantermos as entidades com a estrutura necessária para atender aquele contexto específico, caso contrário, podemos degradar a performance e termos dificuldades na manutenção e evolução da aplicação.

Migrando de DAAB para Dapper

Um dos pilares do antigo Enterprise Library é o DAAB (Data Access Application Block), e como o próprio nome diz, é um componente que auxilia na extração de dados de uma base de dados relacional. Sua API fornece métodos que permitem executar consultas que retornam valore escalares e também materializar o resultado em objetos.

É importante salientar que ele não é um ORM, e sendo assim, não rastreia mudanças em objetos depois que eles são materializados; compete ao cliente que faz uso desta biblioteca gerenciar tais mudanças que ocorrem nos mesmos, para depois devolver as alterações para a base de dados executando comandos de UPDATE, DELETE ou INSERT.

Abaixo um exemplo simples de como materializar o resultado para um objeto. Além da consulta SQL, temos que ter um gerador de parâmetros que os cria e anexa ao comando e, por fim, um builder, que permite customizar o mapeamento entre o resultado e as propriedades expostas pela classe mencionada.

var cliente =
database.CreateSqlStringAccessor<Cliente>
(
@"
SELECT
 c.ClienteId As 'Id'
, e.RazaoSocial
, e.Cnpj
FROM Cliente c
INNER JOIN Empresa e ON e.EmpresaId = c.EmpresaId
WHERE
c.ClienteId = @p0",
new ParameterMapper(),
MapBuilder<Cliente>
.MapNoProperties()
.MapByName(c => c.Id)
.MapByName(c => c.RazaoSocial)
.MapByName(c => c.Cnpj)
.Build()
).Execute(clienteId).SingleOrDefault();

O método 
CreateSqlStringAccessor<TResult> possui uma sobrecarga que permite apenas passar a consulta, e o mapeamento é feito de forma automática se ele encontrar as propriedades com os mesmos nomes das colunas. Além destes facilitadores para converter o resultado em objetos conhecidos pela aplicação, o DAAB gerencia a conexão para nós, ou seja, ele abre o mais tarde e fecha o mais cedo possível.

Isso é válido, pois evita precisamos gerenciar manualmente a conexão, pois algum descuido pode deixá-la aberta consumindo recursos desnecessários ou esgotar a quantidade máxima de conexões que o banco de dados possui. Só que em alguns casos o que queremos é manter a conexão aberta para executar mais de uma consulta, pois o fechamento e a abertura logo em seguida pode ser mais oneroso do que mante-la aberta por um curto período de tempo. E quando isso é necessário, temos novamente que voltar a lidar com as classes já tão conhecidas para trabalhar com dados no .NET (Connection, Command, DataReader, Parameter, etc.).

Infelizmente já faz algum tempo que esta biblioteca não sofre atualização (2013). Como uma - boa - alternativa, um Micro-ORM chamado Dapper foi criado por
 Sam Saffron e Marc Gravell para ser usado pelo site StackOverflow (um grande case de performance) e hoje é open-source e pode ser utilizado por nossas aplicações. Ele foi criado com foco em performance, otimizando e reutilizando internamente objetos para tornar as consultas recorrentes cada vez mais veloz.

A sua API é extremamente simples, e faz uso de métodos de extensão na sobre a interface IDbConnection para materializar o resultado em objetos. Através de um método genérico chamado Query<T>, nós informamos a consulta SQL, e a parametrização é bem mais simples de se configurar, pois basta informar os parâmetros através de objetos anônimos, que o Dapper irá mapear as propriedades do objeto em parâmetros na consulta SQL.

using (var conn = new SqlConnection("Data Source=.;Initial Catalog=Dados;Integrated Security=True"))

{
    var cliente = conn.Query<Cliente>

(@"
SELECT
              c.ClienteId As 'Id'
    , e.RazaoSocial
    , e.Cnpj
FROM Cliente c
INNER JOIN Empresa e ON e.EmpresaId = c.EmpresaId
WHERE
    c.ClienteId = @id", new { id = 2688 }
).SingleOrDefault();

    Console.WriteLine(cliente.RazaoSocial);
}

Aqui, como podemos notar, somos nós que temos que gerenciar a conexão, mas ao contrário do que ocorre com o DAAB, a forma de se escrever é bem mais simples. E como é possível notar no próprio site do projeto, o uso desta biblioteca é extremamente eficiente.

Event Sourcing - Parte 2

Dando continuidade ao post anterior, por questões de simplicidade,  armazenávamos os eventos gerados para uma entidade em memória, algo que não é útil em ambiente de produção.

Como alternativa a isso, podemos recorrer à algum repositório que persista fisicamente as informações. O uso de uma base de dados relacional pode ser útil, porém é necessário que você utilize colunas que possam armazenar o objeto serializado (varbinary, varchar(max), etc.).

Isso é necessário porque é difícil prever o schema. Podem haver muitos eventos, novos eventos podem acontecer, novas informações podem ser propagadas; será difícil evoluir o schema na mesma velocidade.

Uma alternativa aqui é utilizar uma base no-sql. Apesar de alguns nomes já virem a cabeça, existe uma chamada GetEventStore. Ela foi desenhada para dar  suporte à cenários de event sourcing, e sua API também dispõe de métodos e facilitadores que permitem gravar e ler eventos sem dificuldades.

O GetEventStore também permite o acesso a leitura e gravação através de HTTP, possibilitando assim que outras tecnologias, incluindo JavaScript, possam também usufruir dela.

Por fim, ele também permite a gestão da base de eventos através de um interface web, onde podemos interagir, diagnosticar e monitorar os recursos que são necessários para o seu funcionamento.

O vídeo abaixo altera o projeto criado anteriormente para fazer uso do GetEventStore. E tudo o que precisamos alterar é a classe RepositorioDeEventos; o resto da aplicação se comporta da mesma forma, porém com os dados sendo persistidos fisicamente. Se desejar, pode baixar o projeto clicando aqui.

Event Sourcing - Parte 1

Todos temos uma conta bancária. Além das informações cadastrais, muito provavelmente ela também possui o saldo atual, que representa o quanto temos naquele exato momento, podendo ser positivo, negativo ou simplesmente zero.

O saldo, subindo ou descendo, queremos, obrigatoriamente, saber como ele chegou naquele valor. É importante saber o saldo que tínhamos em uma determinada data (retroativa) e o que aconteceu para ele atingir o saldo atual.

Felizmente todos os bancos dão aos seus correntistas o extrato de sua respectiva conta. É com ele que vamos conseguir enxergar o aumento ou diminuição do nosso dinheiro. Posicionado em uma data, identificando o saldo daquele dia, se viermos somando os valores (lembrando que pode ser positivo ou negativo), chegaremos ao saldo atual da conta. Claro, se nada estiver errado.

Tecnicamente falando, é provável que no banco de dados tenhamos uma estrutura de duas tabelas, onde uma teria os dados cadastrais da conta e a outra os lançamentos. A tabela pai provavelmente também irá armazenar o saldo atual da conta e outras características.



A medida em que os lançamentos são inseridos na segunda tabela, a coluna saldo da primeira vai sendo sensibilizado para refletir o saldo atual da conta. O valor atual do saldo vai sendo sobrescrito com o novo valor.

Já está claro que o importante para o dia a dia é o valor que temos disponível, ou seja, o saldo atual. Os lançamentos são necessários, até então, apenas para histórico; na maioria das vezes, eles são dispensáveis para operar a conta corrente (pagar contas, realizar saques, sacar dinheiro, etc.). Agora, considere o exemplo abaixo:



Repare que o saldo atual que temos não corresponde a soma dos lançamentos da segunda tabela. É provável que nosso sistema possua um bug, que afeta diretamente a atualização do saldo atual.

Apesar de, teoricamente, os lançamentos estarem corretos, é difícil diagnosticar o problema, já que não é possível, de uma forma fácil, reproduzir os mesmos eventos, exatamente da forma em que eles aconteceram, para só assim identificar onde e quando o problema de fato ocorreu.

Eis que entra em cena o Event Sourcing. Ao invés de armazenar o estado atual da entidade em colunas e linhas, o uso desta técnica determina que se armazene uma sequência (stream) de eventos, onde cada um deles informa a ação que foi executada sobre a entidade. Quando esses eventos são recarregados, eles são reaplicados contra a entidade, reconstruindo a mesma. Depois de todos eventos processados, a entidade terá, novamente, o seu estado (versão) atual. Neste modelo não fazemos a persistência física das propriedades na base de dados.

Versionamento

Uma das preocupações neste modelo é com o versionamento da entidade. É através de versão que vamos controlar o processamento e aplicação dos eventos. A versão irá garantir que um evento não seja aplicado à entidade depois que outro evento tenha se antecipado e alterado o estado da mesma em relação ao momento em que ela foi construída, ou melhor, carregada.

Isso é conhecido como concorrência otimista. É algo que também já fazemos com o banco de dados relacional, comparando o valor anterior com o atual que está na tabela antes de proceder com o comando de UPDATE ou de DELETE. O controle pode ser feito de várias maneiras, mas para ser simplista, podemos nos ater ao uso de um número inteiro, que vai sendo incrementado a medida em que um novo evento é aplicado.

Snapshots

Ao longo do tempo, mais e mais eventos vão sendo adicionados e, eventualmente, a performance pode ser degradada. Neste caso, uma possível solução é a criação de snapshots, que depois de carregado os eventos, reaplicados na entidade, ela pode disponibilizar métodos para expor o seu estado atual.

Os snapshots também são armazenados e quando a entidade for recarregada, primeiramente devemos avaliar a existência dele antes de reaplicar os eventos. Se houver um snapshot, restauramos o estado da entidade e reaplicaremos os eventos que aconteceram do momento do snapshot para frente, não havendo a necessidade de percorrer toda a sequência de eventos, ganhando assim em performance. Tão importante quanto o estado atual, o snapshot também deve armazenar a versão atual da entidade, pois esta informação é essencial para o correto funcionamento dos snapshots. Essa rotina de criação de snapshots pode ser feita em background, em uma janela de baixa atividade do sistema, podendo ser implementado através de uma tarefa do Windows que roda periodicamente ou até mesmo com um Windows Service. Para a criação de snapshots, podemos recorrer ao padrão Memento, que nos permite expor e restaurar o estado sem violar o encapsulamento do objeto.

Naturalmente o cenário de conta corrente que vimos acima quase se encaixa perfeitamente neste modelo, exceto pelo fato de termos o saldo atual sumarizado e armazenado fisicamente. Vamos então transformar uma simples classe com uma coleção de lançamentos em um modelo que suporte a técnica descrita pelo Event Sourcing. Vale lembrar que isso é "apenas" mais uma forma de persistência. Você pode ter situações que talvez esse modelo seja útil e necessário, já para outros ambientes, pode ser considerado overkill.

MessageQueue e HTTP

Quando trabalhamos com o Microsoft Message Queue, serviço de mensagens fornecido pelo Windows, ele nos permite expor as filas através do protocolo HTTP. Isso permitirá apenas o envio de mensagens através deste protocolo (podendo também ser via HTTPS), e com isso, clientes que estiverem além dos limites da empresa, poderão enfileirar mensagens para o processamento interno de alguma rotina que rodará periodicamente.

Apenas o envio é permitido via HTTP, pois somente a porta 80 é necessária para executar esta ação; para recepcionar a mensagem, é exigido que outras portas também estejam abertas no firewall, e devido a isso, a Microsoft optou por não permitir o recebimento de mensagens sobre estes protocolos.

Para fazer uso deste recurso, ao instalar o Message Queue no computador que receberá as mensagens, você deve marcar a opção de suporte ao protocolo HTTP, conforme é mostrado na imagem abaixo. Vale lembrar que esta opção exige que o IIS (Internet Information Services) também esteja instalado nesta mesma máquina.


Depois de instalado, o Message Queue cria uma diretório virtual dentro do IIS, que servirá o ponto de acesso (HTTP/S) para as filas criadas nesta máquina. Abaixo vemos a fila chamada "Exemplo" criada e o diretório virtual chamado "MSMQ".


Por fim, ao fazer uso da API System.Messaging, podemos apontar para o endereço HTTP, combinando o diretório virtual criado com o nome da fila para qual queremos enviar a mensagem.

using (var mq = new MessageQueue("FormatName:DIRECT=http://localhost/msmq/private$/exemplo"))
    mq.Send("Algo Aqui", MessageQueueTransactionType.Single);

Apesar disso ser possível, considere o uso do WCF com MessageQueue.

Desenvolvimento de UIs

Por mais simples e fina que ela seja, uma das partes mais importantes de um sistema deskop, web ou mobile, é a interface gráfica. Por mais complexo e tecnológico que seja as camadas mais baixas da aplicação, independentemente dos padrões de arquitetura e projeto que utilize, se é uma base de dados relacional ou No-SQL, etc., é a interface com o usuário que receberá a maior parte das interações e é ela que inicialmente é apresentada quando se propõe ou vendo uma solução.

Além da interface ser a principal responsável por capturar informações e devolver respostas (de sucesso ou falha), é ela também quem exibe os dados para que os usuários realizem a análise gerencial e operacional da empresa para qual o sistema foi desenvolvido.

Apesar de existir uma porção de artigos e documentações que descrevem boas práticas para a construção de interfaces, o bom entendimento do negócio garantirá aos desenvolvedores a criação e otimização de telas para que em pouco espaço, sejamos capazes de apresentar poucos dados, mas com muitas informações.

A ideia é repensar a forma como as construímos, tendo em mente a atividade (ou tarefa) que o usuário irá desempenhar naquela tela. Entender a essência do problema é crucial para o sucesso da criação das telas, e o usuário que é o responsável por executar a tal atividade dentro da empresa é a melhor pessoa com quem se pode falar para extrair as dificuldades/exigências. Em seguida, temos que tentar abstrair tudo de importante que foi colhido, e por fim, implementar.

Abaixo estão algumas técnicas que utilizamos na construção de aplicações para a empresa em que trabalho. A ideia aqui é exibir alguns conceitos, dificuldades e soluções que foram encontradas e implementadas. Apesar dos exemplos serem aplicações desktop (WPF) e web, eles não se limitam a estes cenários; nada impede de utilizar estes conceitos na construção de um aplicativo móvel.

Observação: clique nas imagens para visualiza-las em um tamanho maior.

Dashboards

Todos os funcionários da empresa têm atividades diárias. Algumas pessoas estão condicionadas a executar sempre as mesmas tarefas, analisar os mesmos dados. Se conseguirmos mapear tudo o que ele deve olhar e monitorar, podemos criar um painel que concentra todas as informações que coordenarão o seu dia.

Bem-vindo aos dashboards. Assim como o painel de um carro, que centraliza todas as informações relevantes para a condução e monitoramento do mesmo, os dashboards em uma aplicação tem o mesmo sentido. Se começar a setorizar a sua empresa, irá perceber que cada departamento terá ações distintas (muitas vezes, sobre os mesmos dados), e antes dele sair analisando um a um para saber se há problemas, porque já não apontar as divergências para que ele resolva?

Além disso, os dashboards muitas vezes exibem informações e índices sobre a saúde de algum recurso da empresa, sobre dados financeiros, etc., para que pessoas de nível gerencial possam acompanhar e tomar as decisões cabíveis para cada situação. Reportar periodicamente tais informações garante que ele possa reagir assim que detecta algo suspeito.



Análises

Além dos dashboards que dão uma visão mais panorâmica sobre certos aspectos, há telas que podem concentrar informações mais detalhadas a respeito de algo ou alguém. Por exemplo, qual o risco atual do cliente XYZ? Qual a posição do meu estoque?

Quando colocamos várias informações lado a lado, temos que de alguma forma evidenciar algumas delas, separando muitas vezes por severidade. Existem índices que servem como histórico, enquanto outros indicam a quantidade e total de títulos vencidos que a empresa possui. Saber diferenciar entre essas duas informações garantirá o sucesso da tela, pois é com essa segmentação do que é ou não crítico que vamos utilizar para desenhar e destinar os espaços necessários para cada seção.

O tamanho da fonte é um importante aliado no momento em que precisamos destacar certos valores. A parte superior da tela sempre me pareceu o primeiro ponto em que olhamos quando a mesma é aberta. E aproveitando este instinto, podemos concentrar em uma linha horizontal as informações mais críticas do cliente, enquanto o restante da tela exibe informações de menor severidade, mas não tão menos importantes.



É claro que isso não é uma regra. Você pode optar por utilizar o canto direito, canto esquerdo, etc., para concentrar informações de análise acerca do que está olhando naquele momento. Abaixo está um outro cenário, agora web, que apresenta a situação atual de uma empresa na mesma tela em que exibe os seus títulos em aberto e algumas outras informações de histórico.



Por fim, é importante dizer que nada é estático. A maioria dos índices podem ser (e na maioria das vezes serão) clicáveis. O que quero dizer é que ao clicar no total de vencidos, será apresentado uma tela contendo os títulos que compõem aquele valor.

Repare que essa forma muda como o usuário pensa. Algumas vezes, tudo o que o usuário quer saber é quanto a empresa XYZ está devendo; não importa quantos títulos são. Em geral, o que se apresenta é uma tela contendo vários tipos de filtros, onde um deles é o código/CNPJ da empresa em questão, que ao clicar em filtrar, os 4822 títulos são listados.

Neste outro modelo proposto, basta ele chegar até a empresa e já terá uma sumarização, as pendências não concluídas, sendo possível apontar os títulos que estão vencidos (que ele precisa atuar).

Cores

O tamanho da fonte não é o seu único aliado no momento de destacar informações. As cores também podem representar muita coisa. Além do verde (positivo), vermelho (negativo), azul (indiferente) e amarelo (alerta), podemos abusar das mais diversas cores para indicar algum comportamento, evolução ou tendência de alguma informação.

As cores não se restringem apenas aos índices. Você pode optar por colorir diversas partes do sistema, como por exemplo, o contorno de uma janela que exibe a nota daquele cliente. Repare que a nota, o número propriamente dito, começa a ser irrelevante, já que todo o contexto gráfico indica que aquele é um cliente ruim, independente da escala utilizada (1 a 5, 1 a 10, 10 a 100, etc.).





Gráficos

Gráficos são recursos que cabem na maioria das aplicações. O importante é sempre ter um bom componente à mão para que seja fácil a criação, já que gráficos podem ser criados aos montes, cruzando diversos tipos de informações.



O maior desafio não é a parte técnica, mas sim as informações que compõem o gráfico. Com o conhecimento do negócio é possível que você sugira algumas opções predefinidas, mas é o usuário, com o conhecimento e experiência, que pode indicar quais os melhores gráficos para enriquecer a aplicação.

Sempre há uma discussão em torno disso, que é: criar manualmente cada gráfico ou disponibilizar os dados para que alguma ferramenta externa (Excel, Power BI, etc.)? É uma decisão difícil, pois a construção de gráficos é estática, ou seja, se quiser um novo gráfico, precisamos criar uma nova tela, extrair os dados e exibir, compilar e redistribuir, ao contrário dessas ferramentas específicas, que recebem um conjunto de dados e você molda como preferir.

Ao meu ver, a vantagem de ter o gráfico dentro da aplicação é a possibilidade de inserir o mesmo em um contexto específico, como por exemplo, colocar lado a lado com outras informações que estão sendo analisadas no momento da aprovação de alguma operação.



Contexto

Informações de contexto são sempre bem-vindas quando está analisando ou tomando alguma decisão. São informações que estão conectadas de alguma forma com o que está sendo analisado, e não estou me referindo à banco de dados aqui. Situações onde você está avaliando o crédito para uma empresa e vê que ela está devendo R$ 200.000,00 no mercado, e com apenas um clique, você consegue chegar rapidamente a lista de credores e seus respectivos valores.

Elas podem estar na mesma tela de análise, mas mesmo que haja espaço suficiente para ela, sacar a informação de algum outro lugar pode ser mais interessante, pois evita o risco de poluir demasiadamente a tela. Temos que ponderar entre a discrição e a facilidade de acesso à informação. Considere o exemplo abaixo, onde há uma operação de crédito sendo analisada, qual já possui diversos parâmetros, mas se o usuário desejar, pode acessar as últimas operações realizadas para definir a taxa que será aplicada à operação corrente. A janela que aparece é apenas uma tooltip.



Interação

Nem sempre as aplicações têm uma área de ajuda, pois não é algo fácil de fazer e, principalmente, de manter. Muitas vezes ela nunca é utilizada, pois é mais fácil ligar para alguém e perguntar sobre a dificuldade em fazer alguma atividade dentro do sistema.

Ao invés de criar uma área de ajuda, que concentra 100% das informações e detalhamento de como utilizar seções do sistema, a forma mais simples e intuitiva seria espalhar pelas telas da aplicação informações que ajudem o usuário a esclarecer possíveis dúvidas que ele tenha no momento da realização de uma determinada tarefa.



Repare que com poucas palavras é possível esclarecer um termo que à primeira vista parece ser complexo e confunde o usuário na escolha. A mesma regra pode se aplicada na descrição de um link que ele pode estar na dúvida em qual deles escolher:



Feedback

Reportar falha de execução de alguma atividade (seja de infraestrutura ou de negócio) é fácil, pois basta indicar o motivo do erro e pedir para o usuário tentar novamente. Mas o grande desafio é notificar, de forma simples e objetiva, a conclusão da mesma.

Não estou falando aqui de "cadastro realizado com sucesso", "operação enviada para análise", etc., mas sim de exibir detalhes precisos da atividade que o usuário acabou de realizar. Quando você dá entrada em algum órgão, é comum eles darem um protocolo indicando o número, a data, o prazo de conclusão, o nome, etc. Poderíamos utilizar a mesma regra aqui, ou seja, quando a atividade for concluída, podemos exibir na tela detalhes que o deixem seguro de que a mesma foi executada com sucesso.



É claro que isso nem sempre é possível ou viável. Processos simples também demandam mensagens mais simples. Mas considere mesmo estes casos simples para ser mais esclarecedor com o usuário, indicando com mais ênfase o que acabou de ser realizado. Opte por "A empresa teve a sua razão social alterada de Israel Aece-ME para Israel Aece Ltda." ao invés de "Alteração realizada com sucesso.".

Foco em Tarefas

No nível mais baixo, sabemos que tudo o que um sistema faz em uma base de dados é inserir, atualizar, excluir e ler os dados(CRUD). Só que se ficarmos preso a este modelo de trabalho, vamos construir telas que simplesmente farão estas quatro operações básicas, orientando elas a serem voltadas para a estrutura do nosso banco de dados.

Só que as telas podem dizer muita coisa sobre o comportamento e as atividades que devemos fazer com os dados, que nem sempre se referem à apenas uma única entidade. Muitas vezes a atividade é composta de diversas outras subatividades, que contribuem para a totalidade de uma tarefa a ser executada.

Imagine que você tem um cliente e ele está bloqueado de operar. A implementação mais trivial possível no banco de dados é ter uma tabela chamada "Cliente" com um flag chamado "Bloqueado". Como seria a construção da tela que desbloqueia o cliente?

Geralmente temos um formulário que você edita todos os dados, e nele está incluído um checkbox que está associado à coluna "Bloqueado". Ao clicar no botão atualizar, os dados são persistidos na base de dados e o cliente está apto a operar novamente. Mas essencialmente será que o desbloqueio seria apenas isso? Será que o desbloqueio não seria algo muito maior, que depende que alguém solicite e outra pessoa seja responsável por analisar o motivo e autorizar o não o desbloqueio? Será que não precisamos de histórico de alteração? Qual a justificativa para o desbloqueio? Qual a razão de aceitar o desbloqueio?



Isso é um exemplo de uma tarefa que você executa contra o seu cliente, ou seja, solicitar o seu desbloqueio. Não é um simples formulário de edição. Se você pensar orientando à tarefas que podem ser executadas naquela entidade, é provável que nem precise de um formulário para isso. Aos poucos você começa a perceber que as telas da aplicação desencadeiam ações.



Suas telas deixam de serem formulários baseados na base de dados. Elas possam a ser desenhadas de acordo com a atividade que aquele usuário deve desempenhar. Se ele é responsável por aprovar a alteração de vencimento de boletos, então podemos relacionar os que estão atualmente na sua alçada e permitir com que ele possa selecionar os que deseja aprovar e escolher a opção de conclusão.



Relatórios

É uma tentação por parte dos usuários. Sempre quando eles querem visualizar alguma massa de dados, eles falam em "relatórios". Para mim, relatório é o que se imprime, ou seja, aquilo que se manda para a impressora. Mesmo que relatórios sejam indispensáveis para aplicações, não quer dizer que eles devem ser utilizados como forma de exibir um conjunto de dados em tela.

Algumas aplicações, por questões de simplicidade, utilizam relatórios para exibição, por exemplo: listar todos os títulos vencidos do Israel, clientes com divergências cadastrais, empresas localizadas em São Paulo, etc. Apesar de isso ser possível, torna a relação estática, ou seja, não é possível clicar no cliente que está sem endereço e ajustar. Teria que imprimir, abrir a tela de cadastro de clientes, localizar o mesmo, e em seguida, fazer a alteração.

Como provavelmente existe uma pessoa responsável pelo cadastro dos clientes, então no dashboard dela poderia existir um índice que indica a quantidade de clientes com divergências, e ao clicar, uma tela seria apresentada com esta relação; bastaria dar um clique e já ajustar o endereço e ao sair, a relação já seria sensibilizada e o cliente recém alterado iria desaparecer. As telas tem um grande poder, pois pequenas sumarizações servem também de filtro para uma listagem, sem a necessidade de ter um formulário de pesquisa para isso.



Outro ponto importante a ser considerado é segurança. A impressão de relatórios permite com que algum funcionário mal-intencionado imprima e entregue a relação de clientes para um concorrente. Não que com a tela seja impossível de acontecer, mas chama mais atenção alguém fotografando a tela do computador.

Os relatórios precisam ser pensados com cautela, pois como disse acima, é uma tentação para os usuários. É importante entender a essência do problema, focando na atividade que vem após a impressão. Isso nos dará a oportunidade de construir uma tela que atenda a necessidade deles sem a impressão física da relação de dados.

E claro, não há como escapar de desenvolver relatórios. E sem querer se contraditório, eles são sempre bem-vindos.



A ideia deste artigo foi apenas mostrar algumas técnicas que utilizamos no desenvolvimento das aplicações para empresa onde trabalho. Não há nenhuma regra que deve ser assegurada aqui. São apenas experiências que foram vivenciadas e que a escolha, no meu ambiente, se fez válida. Use como quiser.

Utilizando o HSTS

Quando falamos em proteger a comunicação entre a aplicação web e os clientes que a consomem, logo pensamos em HTTPS. Este protocolo tem a finalidade de criar um túnel entre as partes, garantindo com que as informações trafeguem entre os dois pontos mantendo a confidencialidade (ninguém além dos dois consegue visualizar) e a integridade (ninguém consegue alterar).

Quando habilitamos este protocolo na nossa aplicação e também no hosting que hospeda a mesma, não é 100% garantido que a aplicação será acessada através de HTTPS, colocando em risco a segurança, pois alguém no meio do caminho pode interceptar a requisição e explorar todo o seu conteúdo, e o pior, começar a direcionar o usuário para sites maliciosos.

Para um teste simples, considere o site do Banco Itaú. Muitas vezes as pessoas não se atentam em acessar o site digitando o https:// no navegador. Se monitorarmos a requisição para o endereço http://www.itau.com.br, nós veremos que o navegador recebe como resposta o código 301 (Moved Permanently), obrigando o navegador a encaminhar o cliente para o endereço seguro, que é o https://www.itau.com.br.



Ao receber este tipo de resposta e houver alguém interceptando a comunicação, ele pode substituir o endereço do redirecionamento e, consequentemente, nos mandar para um site malicioso, que simula a aparência do banco, e rouba todos os nossos dados. Para evitar isso, um novo recurso chamado HTTP Strict Transport Security (ou apenas HSTS) foi criado e permite à uma aplicação web indicar que ela somente pode ser acessada através do protocolo HTTPS, e em conjunto com o navegador, assegurarão que independentemente do que se tente fazer, a requisição sempre será feita (e as vezes até modificada para realizar) através do protocolo seguro. Para o servidor indicar ao navegador a obrigatoriedade da utilização do HTTPS, ele deve incluir no cabeçalho da resposta o item (chave) Strict-Transport-Security, indicando o tempo (em segundos) em que o cabeçalho será mantido do lado do cliente.

A especificação também contempla um parâmetro neste cabeçalho chamado includeSubDomains, que como o próprio nome indica, subdomínios deste site deverão ter a garantia de que também serão acessíveis somente através do HTTPS.

No ASP.NET 5, que é independente de hosting, podemos incluir este cabeçalho através de um middleware. É importante dizer que segundo a especificação, este cabeçalho só deve ser enviado ao cliente quando ele já estiver dentro de uma conexão protegida. E esta validação pode ser feita através da propriedade IsHttps que é exposta pelo objeto que representa a requisição.

public class HstsMiddleware
{
    private readonly RequestDelegate next;
    private readonly TimeSpan maxAge;

    public HstsMiddleware(RequestDelegate next, TimeSpan maxAge)
    {
        this.next = next;
        this.maxAge = maxAge;
    }

    public async Task Invoke(HttpContext context)
    {
        if (maxAge > TimeSpan.Zero && context.Request.IsHttps)
            context.Response.Headers.Append(
                "Strict-Transport-Security", $"max-age={maxAge.TotalSeconds}");

        await next(context);
    }
}

public static class HstsMiddlewareExtensions
{
    public static IApplicationBuilder UseHsts(this IApplicationBuilder builder, TimeSpan maxAge) => 
        builder.UseMiddleware<HstsMiddleware>(maxAge);
}


Alternativamente você também pode recorrer ao IIS para realizar a configuração do HSTS, e permitir com que os recursos que são disponibilizados por ele também sejam protegidos por HTTPS. A solução foi proposta pelo Doug Wilson e consiste em criar uma regra para sobrescrever o protocolo HTTP para HTTPS utilizando o arquivo de configuração da aplicação ou do servidor.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="HTTP to HTTPS redirect" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                        redirectType="Permanent" />
                </rule>
            </rules>
            <outboundRules>
                <rule name="Add Strict-Transport-Security when HTTPS" enabled="true">
                    <match serverVariable="RESPONSE_Strict_Transport_Security"
                        pattern=".*" />
                    <conditions>
                        <add input="{HTTPS}" pattern="on" ignoreCase="true" />
                    </conditions>
                    <action type="Rewrite" value="max-age=31536000" />
                </rule>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

Preload List

Apesar de garantir que todos os recursos da aplicação serão acessados através do HTTPS, o primeiro problema ainda persiste, ou seja, a requisição inicial para o site do banco pode continuar sendo feita através de HTTP, e a possibilidade de interceptação continua. Para evitar isso, o Google mantém um site (HSTS Preload List) em que podemos adicionar URLs que emitem este cabeçalho, e obviamente, possuem um certificado válido. Isso permitirá ao navegador antes de fazer a requisição para o site avaliar se ele está contido na lista, e se estiver, já transformará a primeira requisição em HTTPS.

Depois da primeira requisição feita, o navegador já é capaz de detectar a necessidade de acessar a aplicação através de HTTPS, e ao acessa-lo via HTTP, o próprio navegador faz um redirecionamento interno (307 - Internal Redirect) e já faz a requisição com HTTPS. É possível ver esse comportamento na imagem abaixo.

Documentação de APIs com Swagger

Há algum tempo eu escrevi aqui sobre o ApiExplorer, que é uma funcionalidade que nos permite expor uma documentação sobre a nossa API. Basicamente ela consiste em nos fornecer metadados dos controllers, ações, parâmetros e resultados para que assim possamos criar uma interface amigável com o usuário (leia-se outro desenvolvedor).

Apesar de termos certa flexibilidade na criação e exibição da documentação, o nosso foco sempre é desenvolvermos a funcionalidade proposta pela API, enquanto a documentação sempre fica em segundo plano, e que na maioria das vezes, nem sempre ganha a atenção que merece. Vale lembrar que é isso que o mundo externo irá utilizar para estudar antes de consumir.

Existe uma especificação chamada Swagger, que tenta padronizar as informações extraídas da APIs Web e, consequentemente, expor de uma forma intuitiva e com bastante riqueza ao mundo. Além do padrão, ainda existe um conjunto de ferramentas (consulte o site oficial), e entre elas, tenho a Swagger UI, que consiste em um conjunto de documentos CSS, HTML e Javascript, e que dinamicamente geram uma interface rica com todas as informações extraídas da API, incluindo o formato das mensagens de requisição e resposta, e ainda, uma opção para já invocar as ações que estão disponíveis, sem precisar recorrer à outras ferramentas, tais como Fiddler. Como um diferencial, os parâmetros já são mapeados e consistidos pela própria interface, garantido que os tipos estejam de acordo com o esperado pela API.

Vale lembrar que o Swagger é completamente independente de plataforma, e não é algo exclusivo do .NET ou da Microsoft. Felizmente existe uma pacote chamado Swashbuckle, que nada mais é que uma implementação desta especificação para Web APIs escritas com o ASP.NET, e que nos bastidores, recorre ao ApiExplorer para gerar a documentação neste - novo - padrão. Por fim, com uma simples linha de código, é possível fazer com que a nossa API tenha uma documentação extremamente rica. Para utiliza-la, basta adicionar o pacote através do Nuget, conforme vemos no comando abaixo:

PM> Install-Package Swashbuckle

Depois de instalado, podemos perceber a criação de uma arquivo chamado SwaggerConfig.cs, que já habilita as configurações mais básicas para o seu funcionamento. Abaixo temos a versão simplificada dela, mas se reparar na classe gerada pela instalação do pacote, há uma série de comentários que são bastante autoexplicativos em relação a cada funcionalidade que ela expõe.

public class SwaggerConfig
{
    public static void Register()
    {
        var thisAssembly = typeof(SwaggerConfig).Assembly;

        GlobalConfiguration.Configuration
            .EnableSwagger(c => c.SingleApiVersion("v1", "Minha API"))
            .EnableSwaggerUi();
    }
}

Com essa configuração realizada, ao rodar a aplicação e colocar /swagger depois do endereço (url) onde está rodando o serviço, teremos a interface com os métodos da nossa API sendo exibidos.



E ao clicar em um dos botões "Try It Out", mais detalhes da requisição e da resposta serão apresentados, e também a ação será invocada na API. Note que se estivéssemos optando por testar uma ação que estivesse sendo exposta através do método HTTP POST, um textarea seria exibido para que você colocasse o corpo da requisição (em JSON ou XML, você escolhe) para assim enviar ao serviço.



Guardando-se as devidas proporções, para quem trabalha ou já trabalhou com SOAP, pode notar certa semelhança com o WSDL (Swagger) e com o SOAP UI (Swagger UI), onde o que vimos aqui, é voltando para o ambiente REST.