Técnicas Avançadas: DataSnap XE - Artigo ClubeDelphi 130

Como já exibido há tempos em edições anteriores da revista Clube Delphi, o DataSnap existe muito antes do Delphi XE aparecer. Em 1997 a Borland lançou o Delphi 3 e juntamente integrado a ele estava o MIDAS (Multitier Distributed Application Services), tecnologia que seguiu com esse nome até 2001, com o lançamento do Delphi 6, e foi renomeada para DataSnap. A biblioteca MIDAS muito antes do Delphi XE já era sinônimo de alto desempenho na criação de aplicações distribuídas que até antes do Delphi 2009 eram baseadas nas tecnologias DCOM, COM+ e BSS.

Vale lembrar que todas estas tecnologias derivaram do antigo COM, criado pela Microsoft em 1993 para suportar comunicação entre processos e muito utilizada em controles Active X, OLE, OLE Automation. O principal problema do DCOM (Distributed Component Object Model) foi a problemática da queda de performance conforme a conexão de clientes aumentava.

COM+ (versão melhorada do antigo Component Object Model) em outro caso, apresentava melhor performance em relação a este problema, porém, ainda utilizava o servidor de aplicação baseado em DLL, o que gerava um problema de distribuição e muitas vezes manutenção. Já o BSS (Borland Socket Server) era uma mistura de tudo isso, utilizando DCOM e Sockets, servidor de aplicação baseado em executável (e não mais DLL), porém, até este modelo que persistiu até a versão 2007 do Delphi, ainda havia a dependência com a tecnologia COM+.

A partir da versão do Delphi 2009 o DataSnap começou a ter uma evolução significativa. A dependência da tecnologia COM+ foi eliminada, e tanto o DataSnap quanto o Framework dbExpress sofreram grandes modificações, dando origem ao novo modelo de desenvolvimento multicamadas. O Delphi 2009 certamente foi um divisor de águas em relação à tecnologia multicamadas. A arquitetura de desenvolvimento de aplicações distribuídas possuía muito mais performance e mais simplicidade no desenvolvimento.

A versão 2009 marcou também o início do suporte à linguagem de notação JSON (Java Script Object Notation) que nada mais é que uma estrutura de dados Java Script muito leve e podendo ser dezenas de vezes mais rápida que a mesma representação de dados em XML. Vale lembrar que a maioria das linguagens já suporta JSON.

Na versão 2010 o mesmo suporte a JSON veio como o principal responsável pela volta do Callback, que não estava presente na versão anterior, iniciou-se também o suporte a servidores REST, transportando dados com notação JSON nativamente. Um outro grande marco desta versão caracterizava a disponibilização do código-fonte da então “fórmula mágica”, o MIDAS, que poderia ser facilmente melhorado. REST é a abreviação de Representational State Transfer ou Transferência de estado representacional. Ele surgiu da tese de doutorado sobre a Web, escrita por Roy Fielding, que foi um dos idealizadores do protocolo HTTP.

Na versão XE do RAD Studio foram realizadas mais melhorias consideráveis em relação às versões anteriores, lembrando que a compatibilidade entre as versões foi mantida. Na última versão foi possível trafegar, sem problemas, dados suportados tanto pelo dbExpress quanto dados JSON.

Para exemplificar melhor, todas as melhorias citadas até aqui, será exposto de maneira simples como utilizar um servidor DataSnap sem criar Transactional / Remote Data Modules (dependentes da tecnologia COM). Outra grande novidade, que facilmente é implementada, é o gerenciamento de conexões com o banco de dados, recurso comumente chamando de Pool de conexões e que embora poucos saibam, é suportado pelo dbExpress desde muito antes disso. Será apresentada a utilização de Generics para o manuseio deste Pool, a partir das conexões recebidas e gerenciadas pelo próprio servidor.

O transporte de objetos entre cliente e servidor utilizando classes genéricas, o que aumenta significativamente a possibilidade de utilização de POO entre as aplicações cliente e servidora, o que é demonstrado aqui por meio de uma classe de cadastro de CEPs.

Também é visto o conceito de redundância de servidores, que resolve um velho problema. Em todos os modelos de aplicação multicamadas (inclusive no DataSnap), quando a aplicação servidora fica indisponível (devido a problemas de conexão, por exemplo), a aplicação cliente torna-se inutilizável. Uma das grandes novidades das novas versões do DataSnap é justamente a facilidade de se implementar um gerenciador de servidores, transferindo a conexão com a aplicação servidora antiga para um novo servidor, que faz com que o problema se torne transparente.

A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da ClubeDelphi DIGITAL
ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,50
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 2,00 (assinante) ou R$ 2,50 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 5,00
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora