Atenção: esse artigo tem um vídeo complementar. Clique e assista!

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.

Nota do DevMan

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.

Nota do DevMan

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.

Nota do DevMan

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. "