O Cronapp, em seu Low-Code, entrega, tanto no web quando no mobile, uma arquitetura MVC, RESTful, com suporte a internacionalização e sensível a fusos horários. Por mais que fique tudo muito fácil e simples com o Cronapp, onde tudo está ao alcance do mouse, é importante observar as boas práticas no desenvolvimento de aplicações modernas, a fim de deixar seu sistema ainda mais limpo, eficaz, bem programado e rápido. Para isso, criamos esse manual para que nossos usuários possam seguir.

Uso de entidades vs fontes de dados

Aconselhamos sempre o uso de fontes de dados ao invés de acesso diretamente às entidades. Primeiro, por segurança. Para expor uma entidade, você terá que expor todas (por padrão e simplicidade elas já são expostas). Mesmo que queira expor uma entidade e bloquear outras, você terá um trabalho extra de entidade por entidade, definindo permissões de segurança e isso pode ser impraticável com sistemas grandes. Segundo, o uso de fonte de dados traz diversos benefícios como: 

• Restrições de dados: é possível definir condições à sua consulta a fim de não expor todos os dados no formulário. Ex: select com where;
• Uso de blocos como fonte: é possível usar blocos para alimentar a fonte dados, criando lógicas para entrega os dados. Ex: blocos com ifs para trazer dados diferentes a partir de uma condição;
• Uso de eventos: eventos como antes e depois de inserir, atualizar, remover etc;
• Validações: nos eventos é possível validar entrada de dados. Ex: CPF válido, data em um intervalo;
• Parâmetros: é possível usar parâmetros na consulta. Ex: filtrar usuários por uma idade passada no parâmetro;
• Campos calculados: é possível adicionar mais campos à fonte de dados através. Ex: calcular idade e exibir em um campo;
• Tratamento de erro: é possível personalizar mensagens de erro;
• Segurança: é possível definir segurança de ações, campos e dados (esse pode ser feito com blocos). Ex: esconder campo salário de quem não for do grupo financeiro;

Validações de Entrada de Dados

As validações de dados devem ser feitas nos eventos antes de inserir, remover ou atualizar de uma fonte de dados do lado do servidor. Você pode validar do lado cliente algumas coisas, por questão de performance, mas elas precisam ser revalidadas do lado servidor. A arquitetura impõe essa boa prática, visto que traz mais segurança na entrada de dados e mais flexibilidade no uso de diferentes dispositivos alimentando a mesma fonte, como por exemplo, uma página web e um aplicativo, alimentando um cadastro e usando a mesma fonte. As fontes de dados viram serviços REST, logo não impede que uma pessoa a chame diretamente através de qualquer outro meio. Logo, se sua validação estiver apenas no cliente, ele conseguirá entrar com dados errados no seu sistema. O desenvolvedores modernos precisam saber que banco, servidor e cliente não podem ser misturar. Uma fonte de dados é um REST e ela tem que "vida" própria e desconhece quem o alimenta.

Bloco Cliente chamando Bloco Servidor

O Cronapp fornece duas funções para um bloco cliente chamar um bloco servidor: a função "Chamar Bloco" e "Chamar Bloco Assíncrono". "Chamar Bloco" usa uma especificação Ajax do navegador de bloqueio síncrono que está ameaçada de descontinuidade pelos navegadores modernos há algum tempo já. Logo, não usem essa função. Nós a mantemos apenas por compatibilidade com sistemas mais antigos (mas será removida no futuro). A função "Chamar Bloco Assíncrono é indicada para esse fim, visto que não bloqueia o navegador, deixando seu sistema mais fluido. 

Valores Padrões

As fontes de dados fornecem um local correto para definir valores padrões para entrada de dados. Muitos clientes usam eventos de cliente "Ao Entrar" e modificam os valores dos componentes. Mais uma vez, não aconselhamos isso, pois é inseguro, pelos mesmos argumentos colocados no tópico sobre "Validações de Entrada de Dados". Logo, assim como as regras de validação, os valores padrões devem estar do lado do servidor. 

Padrões para nomear arquivos

Aconselhamos uso de alguns padrões para nomear elementos do Cronapp como segue:

• Nome de Blocos: devem começar com letra maiúscula, não conter espaços, underline ou qualquer outro caracter especial. Não usem códigos ou siglas. Exemplo: ValidarData, CalcularFolhaDePagamento;
• Nome de Funções de Blocos: mesma regra sobre nome de bloco. Exemplo: Calcular, ObterDataAtual;
• Nome de Arquivos Comuns (xml, txt, json etc): devem ser todo minúsculo, sem caracteres especiais, exceto o "-". Exemplo: meus-dados.xml, propriedades.txt, dados.json;
• Nome de Formulários: mesma regra para arquivos comuns. Exemplo: usuarios.view.html, meus-clientes.view.html;
• Nome de Entidade:  mesma regra sobre nome de bloco. Nunca use plural. Exemplo: Empresa, Usuario, Departamento;
• Nome de Atributo de Entidade: mesma regra sobre nome de bloco, porém o primeiro caracter deve ser minúsculo. Exemplo: id, nomePrincipal, dataDeCriacao, cpf, cnpj;
• Nome de Relatórios: mesma regra para arquivos comuns. Exemplo: lista-de-usuarios.report, folha.report;
• Nome de Pacotes ou Pastas: todo em minúsculo sem caracteres especiais. Ex: meusrelatorios, finaceiro, dados; 

Uso de Blocos Clientes

É bem comum eventos de tela interagirem com a própria tela. Exemplo: ao selecionar tipo CPF ou CNPJ, o sistema mostra um campo ou outro da tela. Muitos usuários, devido à abstração que o Cronapp traz, não se atentam em usar a camada correta para cada caso. O exemplo dado pode ser executado tanto no cliente quanto no servidor, mas é mais indicado o uso do cliente, pelo motivo óbvio de evitar desperdício de recursos com uma chamada ao servidor com algo que pode ser resolvido no cliente.  

Organize seus blocos em pacotes (pastas)

Devido à velocidade de desenvolvimento, muitos usuários deixam de lado a organização estrutural de seus blocos. É comum vermos listas longas de blocos em uma mesma pasta. Aconselhamos separar blocos em pastas (pacotes)  e subpastas (sub-pacotes) por responsabilidade a fim de evitar um código fonte confuso e desorganizado. Exemplo: pacotes como financeiro, administrativo, util, util/data.

Use Funções

O Cronapp permite a criação de várias funções dentro de um mesmo bloco. É comum vermos usuários criando uma função por bloco, sendo que aquela função só faz sentido para um determinado bloco. Outros casos comuns que vemos são blocos muito longos com pouco reaproveitamento. Tentem reaproveitar mais seus blocos e funções em outros blocos. Não criem blocos muito logos, pois dificulta a leitura e manutenção. Para rotinas comuns, criem blocos utilitários, exemplo, blocos de manipulação de datas, blocos de validação de dados etc.

Uso de Variáveis de Sessão

Aconselhamos evitar uso de variáveis de sessão, pois isso é um limitante de escalabilidade em sistemas modernos. O uso de variável de sessão é permitido no Cronapp quando usamos o tipo de projeto "Sessão" ao invés de "Token". Só mantemos essa opção por compatibilidade, porém ela será removida no futuro. O uso de variável de sessão vai obrigar o balanceador de cargas prender o usuário a um único servidor e isso não é uma boa prática para sistemas modernos, pois representa um grande ponto de falha e gargalo. Prefiram o uso de variáveis no cliente como: variáveis de escopo, formulário ou session storege;

Uso de Views de Banco de Dados

Aconselhamos uso comedido de views de banco de dados, pois isso pode representar um grande problema, caso seu sistema tenha um volume muito grande de dados. Se realmente for usar, procure usar índices e views materializadas.

Uso de Datas e Horas

Trabalhar com data e hora em sistemas modernos requer entender completamente o uso de fuso horários. Uma aplicação web ou mobile é composta, em sua maioria das vezes, de banco de dados, servidor e cliente (navegador web ou aplicativo). É necessário entender bem que o fuso de cada uma dessas camadas pode ter especificações diferentes que podem gerar confusões ao implementar seu sistema. Sugerimos a leitura do documento Entendendo o funcionamento dos tipos data e hora para elucidar todas as dúvidas relacionadas ao uso de data e hora no Cronapp;