Atualmente, quando se pensa no desenvolvimento de software, dois modelos principais podem ser utilizados: o tradicional modelo cliente/servidor ou o modelo multicamadas. A primeira opção consiste somente de duas camadas: o servidor de banco de dados e a aplicação cliente. Nesse contexto, todas as regras de negócio podem ficar centralizadas tanto na primeira quanto na segunda camada (ou em ambas), e a aplicação cliente acessa diretamente a base de dados. Já no modelo multicamadas existe uma porção de software adicional, que é chamada de servidor de aplicação. Essa camada é responsável por armazenar todas as regras de negócio, e é ela quem interage diretamente com a base de dados, ou seja, nesse modelo a aplicação cliente não tem acesso direto ao servidor de banco de dados. Em suma, a aplicação cliente acessa o servidor de aplicação, enquanto que o servidor de aplicação é quem acessa diretamente a base de dados.
A implementação dessa arquitetura de software possibilita uma série de vantagens, como o balanceamento de carga, que permite definir o número máximo de conexões que um servidor pode suportar, e, quando atingido o limite todo o novo tráfego é automaticamente direcionado para servidores menos ocupados. Algumas outras vantagens desse modelo são: centralização das regras de negócio no servidor (não existem comandos SQL na aplicação cliente); facilidade de redistribuição da aplicação cliente; economia de licenças de acesso a bases de dados; economia de conexões no servidor e escalabilidade.
Uma dúvida muito comum dos desenvolvedores, principalmente na construção de aplicativos móveis, é como definir a arquitetura correta de um app que acessa uma base de dados remota. Nesse contexto, não é uma prática muito comum utilizar o modelo cliente/servidor assim como feito em aplicações desktop, ou seja, fazer uso de componentes de acesso direto a dados conectando em bases de dados remotas. Em aplicativos móveis, deve-se usar componentes de acesso direto aos dados (TFDConnection ou TFDQuery, por exemplo) quando a base de dados é local e está gravada no próprio aparelho, o que normalmente ocorre utilizando o SQLite. Porém, quando há a necessidade de acesso externo, o recomendável é a utilização de um servidor de aplicação.
Baseado nisso, o objetivo do presente artigo é mostrar como construir uma arquitetura multicamadas utilizando o Delphi 10.1 Berlin com o SQL Server como o sistema gerenciador de banco de dados. Será mostrado como construir as três camadas desse modelo, partindo da criação da base de dados e implementando também o servidor e a aplicação cliente. O intuito principal é apresentar como a aplicação cliente acessa dados remotos de datasets e incorpora os registros em um ListView, utilizando para isso componentes TFDMemTable. Serão construídos três exemplos de métodos remotos: um para buscar na base de dados a pessoa com o maior salário e retornar o valor; uma pesquisa de pessoas por nome; e, por fim, como trafegar datasets mestre/detalhe pela rede e visualizar seus dados no ListView. Para isso, será utilizado o conceito REST bem como o tráfego de arquivos JSON.
Criando a base de dados
O primeiro passo é a criação da camada de banco de dados da nossa aplicação e, para isso, a Listagem 1 apresenta os comandos SQL para a criação da base de dados e a definição das tabelas no SQL Server. Na linha 1 encontra-se o comando para a criação do banco, enquanto que entre as linhas 2 e 6 está localizado o comando que define a tabela de funcionários, a qual possui um campo chave primária autoincremento (idfuncionario), um nome e o valor do salário. Em seguida, entre as linhas 7 e 12 está o script para gerar a tabela de endereços dos funcionários, que diz respeito ao relacionamento mestre-detalhe (m ...
Desbloqueie toda a DevMedia
-
+2000 artigos e vídeos
-
+40 trilhas sobre Front-end, Back-end, IA e muito mais
-
+5000 exercícios práticos
-
Mentorias ao vivo individuais
Confira outros conteúdos:
Instalando o ACBr
Mapeamento Objeto-Relacional com TMS...
Introdução aos componentes JEDI
Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.