Atenção: esse artigo tem um vídeo complementar. Clique e assista!
O artigo trata do desenvolvimento de servidores de aplicação utilizando a nova arquitetura DataSnap disponível no Delphi 2010. Veremos como disponibilizar serviços web aplicando os conceitos REST trabalhando com notação JSON permitindo assim que nossos serviços possam ser consumidos por aplicações desenvolvidas por praticamente qualquer linguagem de programação. No nosso exemplo utilizaremos jQuery com AJAX para consumir os serviços permitindo a você aplicar os conceitos utilizando C#, PHP, Delphi etc.
Para que serve
A arquitetura em camadas é uma das mais utilizadas em sistemas de grande porte, pois este tipo de arquitetura nos permite ter um sistema mais escalável e de fácil manutenção. Ao permitir que um servidor de aplicação possa ser consumido via web estamos aumentando consideravelmente seu nível de escalabilidade e entrando no mundo dos serviços web. Quando esta disposição dos serviços na web é feita utilizando o conceito REST estamos aplicando o que há de melhor no mercado para esta tarefa.
Em que situação o tema é útil
Desenvolver uma aplicação em camadas é útil quando queremos concentrar nossas regras de negócio em um único lugar, encapsulando a implementação, facilitando a manutenção e aumentando a escalabilidade. Publicar este serviço na web ou permitir que o mesmo seja consumido via HTTP também é extremamente útil, pois desta maneira abstraímos ainda mais os detalhes da aplicação e permitimos assim que clientes desenvolvidos em diferentes linguagens possam utilizar nossos serviços.
Resumo do DevMan
O desenvolvimento de aplicações em camadas sempre foi um capítulo à parte no Delphi. No início a tecnologia era chamada de Midas, logo depois foi batizada de DataSnap. Quando começou, a tecnologia era dependente de COM, porém com o lançamento do Delphi 2009 ela passou a funcionar sobre o framework DBExpress. Agora com o Delphi 2010 a arquitetura DataSnap deu um novo salto e desta vez bem grande. Agora podemos criar servidores DataSnap RESTful e trafegar dados com notação JSON, tudo isso nativamente no Delphi 2010. Neste artigo, após entendermos como funcionam as novas tecnologias vamos criar um servidor DataSnap, em seguida será adicionado suporte à HTTP para que na sequência nosso servidor possa ser consumido por um cliente utilizando jQuery com AJAX.
Muitos desenvolvedores fazem confusão quando o assunto é desenvolvimento em camadas. Pode soar estranho o que vou falar, mas criar uma aplicação com DataSetProvider de um lado e ClientDataSet de outro não significa que você está criando um servidor de aplicação. O termo servidor de aplicação ou aplicação em camadas vai além disso. O conceito de aplicação em camadas é poder ter em uma aplicação, geralmente chamada de servidor de aplicação, todas as suas regras de negócio e permitir que essas regras sejam consumidas por aplicações clientes. O grande equívoco é pensar que se desenvolvemos um servidor de aplicação com Delphi os clientes só podem ser aplicações Delphi, pelo contrário. O objetivo de um servidor de aplicação é justamente inverso.
É aí que muitos desenvolvedores Delphi perdiam o melhor da arquitetura DataSnap. Mesmo com a versão anterior do DataSnap era possível que uma aplicação não Delphi consumisse um servidor feito em Delphi. A mágica por trás disso chamava-se COM. Na arquitetura anterior do DataSnap para criar um servidor de aplicação bastava adicionar um RemoteDataModule. Este componente era na verdade uma coClass, uma classe com suporte à automação, em outras palavras, uma classe que pode ser instanciada remotamente. Ao adicionar um RemoteDataModule era criada uma interface onde poderíamos adicionar métodos para que fossem exportados pelo servidor. Esta interface é na verdade parte da estrutura chamada TypeLibrary, um binário que era um dos produtos da compilação do servidor de aplicação. A TypeLibrary é que era registrada na máquina e não o executável, como muitos pensavam.
Component Object Model (COM) é uma plataforma da Microsoft para componentes de software lançada em 1993. Ela é usada para permitir a comunicação entre processos e a criação dinâmica de objetos em qualquer linguagem de programação que suporte a tecnologia. O termo COM é frequentemente usado no desenvolvimento de software para se referir a um grupo de tecnologias que incluem OLE, OLE Automation, ActiveX, COM+ e DCOM.
As interfaces servem para definir apenas as assinaturas dos métodos, propriedades ou eventos a implementar nas classes. Isto permite separar a definição de uma classe da sua implementação. Em orientação a objetos uma classe que implementa uma interface deve obrigatoriamente implementar concretamente esses métodos.
Com a aplicação criada e os métodos adicionados à interface, bastava informar a quem fosse desenvolver um cliente para o nosso servidor o endereço onde o mesmo se encontrava registrado. Para facilitar o desenvolvimento poderíamos ainda enviar o arquivo com extensão .tlb para que o programador pudesse registrar localmente onde o cliente fosse rodar e então trabalhar diretamente com os métodos da interface que estava descrita na Type Library. O problema é que, na grande maioria das vezes os desenvolvedores adicionavam um RemoteDataModule e simplesmente inseriam ali alguns SqlDataSets e DataSetProviders para que pudessem, do lado cliente, conectar os ClientDataSets nestes Providers através de um componente DComConnection ou SocketConnection. Com isso o servidor de aplicação ficava restrito a clientes desenvolvidos em Delphi. É bem verdade que, da maneira como o DataSnap funcionava, não era nada fácil criar um servidor para clientes não Delphi, era trabalhoso, ainda mais se trabalhássemos com classes e objetos.
Com o passar do tempo a tecnologia COM caiu em desuso e o Delphi precisava acompanhar a evolução tecnológica. Com o lançamento do Delphi 2009 veio também a nova arquitetura, e por que não dizer, o novo framework DataSnap utilizando 100% tecnologia Delphi, uma vez que agora utiliza o DBExpress para conectar o cliente com o servidor de aplicação. Essa mudança quebrou vários paradigmas. O principal deles era a dependência da tecnologia COM, sem falar que agora poderíamos trafegar entre o cliente e o servidor todos os tipos suportados pelo DBExpress incluindo TDBXReader. Mas agora tínhamos um novo problema, se o novo DataSnap não trabalha mais com COM então só poderíamos criar clientes que possuíssem Driver DBExpress. Para a grande maioria isso não seria um problema, pois o cenário era Delphi para Delphi, ou seja, servidor de aplicação Delphi e cliente desenvolvido em Delphi, e para aqueles que desejassem desenvolver clientes Web poderiam optar pelo Delphi Prism, que possuía um Driver DBExpress e portanto poderia facilmente consumir um servidor de aplicação feito com Delphi Win32. Mas e as demais linguagens, como ficam? Imagine uma empresa que gostaria de disponibilizar alguns métodos de seu servidor para os clientes. Como fazer um pedido, consultar uma fatura e etc., se eles trabalhassem com PHP, Java, C#, C++. É exatamente neste cenário que o Delphi 2010 se encaixa.
TDBXReader é uma classe do framework DBExpress 4 que fornece um leitor unidirecional para um conjunto de linhas de base de dados.TDBXReader é retornado por TDBXCommand.ExecuteQuery. O método TDBXReader.Next é utilizado para acessar a primeira linha e caso haja, as sucessivas no result set. Os valores da linha podem ser acessados usando a propriedade Value que é um array. A propriedade Value é sobrecarregada e podemos utilizar tanto a posição da coluna quanto seu nome.
O Delphi Prism é a nova ferramenta da Embarcadero para desenvolvimento de aplicações utilizando .NET. Desde o lançamento do Delphi 2009 temos o Delphi Prism como opção para desenvolvimento Web que é na verdade uma linguagem baseada no compilador Oxygene e que roda dentro da IDE do Visual Studio.
Nova arquitetura DataSnap
No final de 2009 a Embarcadero anunciou o lançamento do Delphi 2010 com uma série de novidades e na área do DataSnap a maior delas. Foi adicionada à arquitetura DataSnap suporte a transporte de dados sobre HTTP, isso mesmo, agora a comunicação entre o cliente e o servidor DataSnap além de poder ser feita via TCP/IP utilizando DBExpress, pode ser feita também via HTTP sem a necessidade de nenhuma tecnologia de terceiros. A partir desta versão é possível desenvolver servidores de aplicação de forma que estes servidores possam ser consumidos por um cliente desenvolvido por praticamente qualquer linguagem de programação graças à arquitetura REST e aos dados trafegados em notação JSON. Mas o que vem a ser de fato REST e para que serve JSON?
...
