Esse artigo faz parte da revista Clube Delphi Edição 56. Clique aqui para ler todos os artigos desta edição

nvolvedores a adotarem o novo modelo, já que muitas empresas buscam soluções nessa área, por uma série de vantagens que destacarei a seguir.

Nossa solução também terá um diferencial: veremos como construir diferentes tipos de aplicação cliente (Windows/VCL, Web etc.) para acessar o mesmo servidor de aplicação, centralizando e compartilhando regras de negócio e de acesso a dados. Ou seja, você poderá fornecer para o seu cliente uma versão Web do sistema (baseada em um browser) ou Windows, de acordo com a necessidade.

Antes de iniciarmos um exemplo prático, vamos relembrar alguns conceitos importantes e necessários para o entendimento da aplicação a ser criada.

 

Dica: consulte a edição 46 para conhecer técnicas de migração de soluções cliente / servidor para DataSnap.

Do modelo cliente / servidor ao multicamadas

O modelo cliente / servidor permite centralizar o armazenamento de dados e as regras de negócio no servidor SQL, que ficam separadas das regras de interface da aplicação cliente.

Um ponto negativo do modelo é a dificuldade de migração de regras e dados de uma tecnologia de servidor de banco de dados para outra (de Firebird para Oracle, por exemplo) e distribuição / manutenção das aplicações clientes. Nesse modelo, a performance e escalabilidade das aplicações podem ficar comprometidas em ambientes com dezenas de conexões clientes simultâneas. Além disso, o custo de licenciamento de uma solução baseada nesse modelo é bastante alta: cada estação de trabalho conectada ao BD geralmente deve pagar por uma licença cliente de acesso.

O modelo multicamadas é uma evolução do modelo cliente / servidor e traz inovações na arquitetura. Nesse modelo temos a separação das regras de negócio do servidor de banco de dados, implementadas agora em uma nova camada, o servidor de aplicação, que também se encarrega do acesso a dados (que não é feito mais diretamente por aplicações clientes). Com essas mudanças, continuamos tendo o processamento das regras de negócio centralizadas, porém agora liberamos o banco de dados dessa função, dando maior portabilidade de nossa base de dados.

Implementar regras e acesso a dados no servidor de aplicação deixará as aplicações clientes mais “leves”, exigindo menos manutenção. Por exemplo, uma mudança em uma regra de validação de dados não exigirá a recompilação e reinstalação de todas as aplicações clientes (também conhecidas com thin-clients), já que elas contêm basicamente regras de tratamento de interface.

E finalmente, aplicações construídas sobre o modelo multicamadas são mais escaláveis, têm maior independência de banco de dados (você pode oferecer um mesmo software que seja compatível com o Firebird, Oracle e SQL Server, por exemplo) e tem custo menor de manutenção e licenciamento.

Agora que sabemos das vantagens do novo modelo, vamos partir para a parte prática! Faremos primeiramente a criação da aplicação servidora, e a seguir da aplicação cliente.

Criando a aplicação servidora

Neste artigo criaremos uma aplicação simples: um cadastro de clientes. A Listagem 1 mostra o código de criação da tabela de clientes e constraints relacionadas. Para criar o banco de dados no Firebird você pode utilizar uma ferramenta como o IBExpert (www.ibexpert.com).

 

Listagem 1. Criação da tabela de Clientes

CREATE TABLE CLIENTES ( ...

Quer ler esse conteúdo completo? Tenha acesso completo