Recursos e limitações
Este aplicativo de demonstração ilustra várias boas práticas, mas é simples o suficiente para ser lido e testado. Como tal, alguns recursos envolvem limitações.
Sobre o que é o aplicativo
É um aplicativo de Ponto de Venda (Point-of-Sale) muito limitado.
Usuários são os operadores.
Usuários com direitos administrativos podem criar outros usuários.
Todos os usuários podem registrar pedidos.
Os pedidos identificam o cliente.
Os pedidos sabem quando foram criados e quando o cliente pagou por eles.
Cada pedido pode ter vários itens.
Itens se referem a certa quantidade de produto.
Produtos têm um preço.
Um Relatório de Vendas exportará e mostrará um arquivo PDF com todos os pedidos registrados.
Existem várias limitações óbvias:
O mesmo usuário pode fazer login a partir de vários dispositivos
Os pedidos não estão registrando o usuário
Pedidos pagos não são somente leitura
O relatório não fornece nenhum filtro
Como ficará claro depois de analisar o código, será fácil superar a maioria das limitações anteriores.
É um aplicativo baseado em banco de dados
Mesmo pequenas aplicações web usam alguma persistência. A persistência mais comum é um banco de dados relacional, compartilhado por múltiplas sessões. É importante selecionar um banco de dados apropriado, capaz de entregar o desempenho esperado (tempo de resposta, concorrência) de acordo com quantas sessões concorrentes a aplicação aceitará.
O aplicativo de demonstração usa SQLite, um banco de dados mais adequado para uso em briefcase.
A única razão para usar SQLite é que o FireDAC o suporta nativamente, sem precisar de nenhum driver externo.
Em vez de SQLite, o Microsoft SQL Server Express (ou LocalDB) poderia ser uma opção melhor.
Se o aplicativo deve ser capaz de suportar ou usar um mecanismo de banco de dados diferente no futuro, em vez de "fixar" a escolha atual, pode ser melhor usar um ORM (ferramenta de mapeamento objeto-relacional). Por exemplo, o seguinte design foi engenharia reversa do banco de dados SQLite por Devart Entity Developer.
A tecnologia de acesso a dados é FireDAC
Como FireDAC é a tecnologia de acesso a dados preferida do Delphi e fornece suporte nativo para SQLite, esta demonstração usa controles de acesso a dados FireDAC.
Como acessar o aplicativo
Como qualquer aplicação web, você precisará de um navegador moderno.
Uma prática padrão é usar um formulário de login para gerenciar os direitos do usuário.
Se usar um formulário de login, é uma boa prática usar SSL (https://unigui.com/doc/online_help/features-and-limitations.htm), mas esta demonstração não usa SSL (apenas http://)
Existem dois pontos de entrada para o aplicativo:
http://:8077 para a experiência completa semelhante a desktop
http://:8077/m para a experiência móvel/com suporte a toque
Controle de acesso
O formulário de login do aplicativo usa o padrão mínimo para autenticar usuários: nome de usuário e senha.
Como de costume, a senha é mascarada com asteriscos.
As senhas não devem ir para o banco de dados. Boas práticas sugerem armazenar um hash em vez disso.
Este aplicativo armazena a senha não criptografada no banco de dados (não é importante mostrar como construir a aplicação uniGUI).
Uma vez que o login seja bem-sucedido, o aplicativo saberá se o usuário atual é um administrador (administradores podem gerenciar a lista de usuários).
Está fora do escopo deste documento, mas RBAC (Controle de Acesso Baseado em Funções) descreve como gerenciar privilégios e papéis (isto é, cada usuário pode atuar em várias funções, cada uma delas concedendo permissões específicas).
Formulário Principal
O formulário principal da aplicação é geralmente a "plataforma de lançamento" da aplicação. É o lugar a partir do qual o usuário executa os módulos da aplicação.
Uma aplicação pequena como esta demonstração terá poucos módulos. Ela usa uma interface em estilo de blocos (menu padrão mais barra de ferramentas ou apenas alguns botões grandes).
Aplicações médias ou grandes com muitos módulos devem usar um paradigma diferente. Um bom começo pode ser usar uma árvore de navegação em um painel à esquerda e um controle de páginas para hospedar os módulos à direita.
Formulário Editar Usuários
Os usuários da aplicação operarão o aplicativo. Administradores podem criar e editar outros usuários, enquanto outros usuários só podem acessar pedidos e relatórios. Além das limitações já mencionadas, há outra limitação que é uma melhoria pendente. O botão na barra de ferramentas permite alternar o status de "admin" do usuário selecionado. Na captura de tela visível, pressionar o botão exibirá uma mensagem "Você precisa de pelo menos uma conta de administrador!", mas se a mesma alteração ocorrer usando a caixa de seleção, ela será aceita. A mesma validação deveria acontecer no evento OnBeforePost da tabela Users.
Armazenar e mostrar as senhas também está errado. Em uma implementação futura desta demonstração aplicaremos algumas melhores práticas sobre segurança de aplicações.
Formulário Editar Pedidos
Este simples aplicativo de Ponto de Venda registrará pedidos com seus itens e identificará o cliente. O banco de dados já contém alguns dados, mas para poder gerenciar todas as informações necessárias, é possível editar clientes e produtos. Cada novo pedido registra o momento em que foi iniciado (Created). Quando o pedido é finalizado e pago, o usuário pressiona o botão (Mask as Paid) e o horário é registrado (Paid).
Observe que um pedido pago deveria tornar-se somente leitura, mas isso não é aplicado nesta implementação.
Relatório de Vendas
Esta é uma demonstração sobre como usar Fast Reports em uma aplicação web. Mostra como modificar as configurações do Fast Report para evitar pop-ups visuais desnecessários, executá-lo em modo thread-safe e consumir recursos sob demanda.
