Introdução ao ADO.NET no Delphi for.NET Preview

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

Dados no Delphi for .NET

Introdução ao ADO.NET no Delphi for.NET Preview

                                                                       Por Guinther de Bitencourt Pauli

Este artigo mostra como fazer acesso a bancos de dados a partir de uma aplicação construída com o Delphi for.NET Preview, usando a tecnologia ADO.NET, integrante do .NET Framework da Microsoft.

Para uma introdução geral ao .NET no Delphi, consulte o artigo de Daniel Polistchuck, na Edição 33, onde são apresentados os fundamentos da plataforma e o uso do compilador de linha de comando do Delphi para .NET. Consulte também a Edição 37, onde é apresentada a versão da VCL para .NET (ainda em processo de migração) e a utilização do Delphi for .NET como linguagem de script para a criação de Web Services em ASP.NET.

Veremos como utilizar o ADO.NET para acessar o SQL Server 2000 (se você não tem esse banco de dados, poderá fazer download de uma versão de avaliação em WWW.microsoft.com/sql). Mas note que, claro, o ADO.NET também dá suporte a vários outros bancos. Conheceremos também alguns detalhes da arquitetura e criaremos vários exemplos.

Antes de começar com a parte prática, no entanto, é necessário destacar alguns pontos importantes:

. Não existe ainda uma IDE para o Delphi for .NET; isso significa que tudo deve ser feito manualmente: criação de componentes, conexão com banco de dados, configuração de layout, de formulários, etc. A IDE está com lançamento previsto para o final do ano;

. A Borland está portando o dbExpress e os componentes da paleta Data Access (inclusive o ClientDataSet) para a plataforma .NET. isso significa que em futuras atualizações do Preview – e na IDE final – você poderá utilizar os mesmos componentes que utiliza hoje, em uma versão adaptada para o .NET (isso vai tornar seus projetos atuais mais compatíveis com a plataforma, facilitando a migração). Até o fechamento desta edição, não havia ainda um update disponível que trouxesse esses componentes adaptados. Porém, boa parte da VCL e da RTL já está portada.

Os exemplos deste artigo foram construídos utilizando o Update 3 do Delphi for .NET Preview (bdn.borland.com/article/0,1410,29780,00.html), rodando sobre o .NET Framework 1.0.3705 (que é a versão recomendada). Utilizamos também o plug – in do Delphi for .NET Preview para  o Delphi7 (bdn.borland.con/article/0,1410,29159,00.html). Para mais informações sobre a instalação do update e do plug – in, veja a edição 37.

São mostrados aqui apenas os fundamentos do ADO.NET, já que o assunto é extenso o suficiente para um livro inteiro – o objetivo principal será mostrar aplicações práticas dessa tecnologia dentro do Delphi for.NET Preview.

Introdução a ADO.NET

O ADO.NET é a tecnologia de acesso a dados do .NET Framework. Uma evolução do ADO (Active Data Objects), é totalmente escrito com código gerenciado (Managed Code). Porém, ainda é possível utilizar os antigos objetos ADO no .NET, por meio de serviços de interoperabilidade e integração usando COM.

Uma importante mudança com relação ao ADO é que agora os DataSets são desconectados, por padrão – algo muito semelhante ao que temos no Delphi com a arquitetura dbExpress/DataSnap e o componente ClientDataSet. Ou seja, os dados são trazidos para uma cachê local, a conexão é fechada, o cliente trabalha “off-line” e, quando precisa atualizar  os dados, uma nova conexão  é restabelecida. Isso torna aplicações do ADO.NET muito escaláveis permitindo que servidores atendam a uma demanda maior de conexões mantendo um desempenho consistente.

Algumas vezes, no entanto, não é uma boa solução conectar e reconectar a um banco de dados a cada transação de uma aplicação cliente. Para esses casos, o ADO.NET oferece um mecanismo de pool de conexões, com o qual uma mesma conexão pode permanecer ativa e atender a um grande número de solicitações.

O ADO.NET foi construído especialmente para aplicações multicamadas e para web. Antes dele, o COM/COM+ era sinônimo de programação distribuída/multicamadas no Windows; no entanto utilizar COM em aplicações multicamadas dificulta a comunicação com clientes que rodem em outras plataformas, além de não ser uma boa solução quando se pretende distribuir informações na web (devido a limitações impostas por firewalls, por exemplo).

Diferentemente do ADO (que é baseado no COM), o ADO.NET utiliza XML para intercambio de dados ganhando, com isso, recursos de integração e interoperabilidade. Além disso, o ADO.NET pode ser utilizado em qualquer linguagem que dê suporte ao .NET, como VB.NET, C# e Delphi for .NET. Isso significa que, se você conhecer o ADO.NET (e demais objetos do .NET Framework), poderá desenvolver aplicações em qualquer linguagem com relativa facilidade.

A seguir conheceremos os principais objetos que compõem a arquitetura ADO.NET. As classes do ADO.NET estão divididas em dois grandes grupos: Managed Providers (provedores gerenciados) e Content Components (componentes de conteúdo).

Managed Providers: visão geral

Os componentes do grupo Managed são responsáveis pelo acesso a dados. Incluem classes para conexão ao banco, gerenciamento de transações, execução de comandos e leitura de dados. Atualmente são distribuídos dois Managed Providers com o .NET Framework: SQL Server Data Provider e OLE DB Data Provider. Você utiliza o primeiro tipo quando precisar criar uma aplicação que se comunique exclusivamente com SQL Server, na versão 7 ou superior.

O segundo tipo permite a comunicação com outros bancos de dados que tenham suporte a drivers OLE DB, como Oracle, DB2, Access, etc. Você pode encontrar, na internet, drivers OLE DB para uma série de bancos, inclusive InterBase, MySQL e muitos outros. No entanto, o uso de OLE DB não é a única opção para acessar bancos de dados a partir de sua aplicação .NET. Muitas empresas fornecem Data Providers nativos para seus bancos (tais como o Borland Data Provider que acompanha o C# Builder).

Cada Managed Provider possui objetos básicos para a comunicação com um servidor de dados, por exemplo: DBConnection, DBComand, DataReader e DataAdapter. No ADO.NET, seguindo um principio importante da orientação a objetos, cada objeto tem uma responsabilidade bem definida e coesa; cada um desempenha uma função definida. Dessa forma, não se pode, por exemplo, passar um comando SQL em um objeto de conexão, ou usar o mesmo componente para conectar, obter dados, fazer cachê e atualizar dados, como se pode fazer com um componente Table.

Managed Providers: objetos comparados

A Tabela1 mostra os principais objetos do grupo Managed Providers. Para que você possa localizar-se mais facilmente é mostrado, para cada objeto/interface, o equivalente na arquitetura dbExpress. Você utilizará os objetos da primeira coluna através de uma das implementações disponíveis (terceira coluna). Por exemplo, no .NET Framework, para usar um DbConnection, você deve optar entre um SqlConnection e um OleDbConnection; para um DataReader, deve-se escolher entre um SqlDataReader ou OleDbDataReader (ou ainda utilizar Data Providers de terceiros).  Os objetos de acesso ao SQL Server estão disponíveis no namespace System.Data.SqlClient; para acesso a Providers OLEDB os objetos ficam no namespace System.Data.OleDb.

Tabela 1. Managed Providers, objetos do .NET Framework e equivalentes no dbExpress do Delphi.

...