ADO x ADO.NET

Nota: Pessoal estive em férias e voltei a todo vapor trazendo muitos artigos sobre VB e VB.NET. Para começar vamos dar uma comparada em duas tecnologias. ADO e ADO.NET.

A tecnologia ADO - ActiveX Data Objects - causou uma grande mudança no tratamento e acesso a fontes de dados pois trouxe muitas inovações que pretendiam otimizar e melhorar o desempenho. Muita coisa no entanto ficou somente no marketing. Com o crescimento da Web e de suas tecnologias criou-se uma grande demanda por aplicações distribuídas e escaláveis ; ficou evidente que a ADO tinha muitos problemas e que alguma coisa precisava ser feita.

Eis que surge então a tecnologia .NET e com ela , o que nos interessa no momento , uma nova maneira de acesso aos dados : ADO.NET. A primeira coisa que você deve fixar é que ADO.NET não é uma atualização da ADO. A tecnologia ADO se baseia no modelo COM - Component Object Model - e a ADO.NET tem seus pilares no XML e no acesso desconectado.

A arquitetura Cliente/servidor tradicional , onde a ADO se sai bem , é geralmente composto por duas camadas : o programa cliente e o servidor de banco de dados , nesta configuração o cliente precisa de muitos recursos para poder executar a aplicação ; usando a ADO precisavamos instalar no cliente: a ADO , o provedor OLEDB , a versão do banco de dados (opcional) , os componentes ActiveX e COM (registrados e instalados).

Em uma aplicação distribuida o programa cliente é desmembrado em mais duas camadas (pelo menos), com uma camada intermediaria entre o cliente e o banco de dados. Nesta camada geralmente ficam as regras de negócio com o isto o cliente fica mais leve e somente vai precisar do sistema operacional , internet e um browser. O problema é que a comunicação entre as camadas é feita geralmente usando conexões da web. O complicador deste ambiente é que o acesso é feito via Internet e com isto fatalmente teremos os seguintes sintomas:

  1. Conexões instáveis e inseguras.
  2. Transmissão e recepção de dados lenta.
  3. Um acesso concorrente muito grande , com centenas/milhares de usuários gerando problemas de colisão de dados.

A ADO.NET veio com a proposta de melhorar estes problemas apresentando as seguintes caracteristicas:

É claro que ADO.NET não é a panacéia universal na arena do acesso aos dados e tem os seus prós e seus contras. A esta altura você pode até estar mais confuso que antes de começar a ler este artigo mas eu espero que ao final você tenha condição de tomar decisões seguras com relação a quando usar ou não ADO e/ou ADO.NET.

Quando usar ou não ADO.NET :

- Se a aplicação que você esta criando vai precisar acessar uma fonte de dados em um ambiente gerenciado tendo como base uma arquitetura ambiente cliente/servidor na WEB , e , se esta fonte de dados pode ser acessada usando os provedores da plataforma .NET. Use ADO.NET.

- Se a fonte de dados não pode ser acessada via provedores da plataforma .NET e/ou é uma aplicação pequena para um ambiente de rede local , talvez aqui você prefira até usar ADO.

Comparando ADO.NET DataSet com ADO Recordset

I)

- Um Recordset ADO tradicional é o coração do acesso aos dados na tecnologia ADO e prove a habilidade de navegar através de uma simples tabela que pode representar a junção de dados provenientes de diversas fonte de dados. Ou seja você junta os dados de diversas tabelas e os acessa em uma única tabela.

- Um DataSet , pelo contrário , suporta muitas tabelas que podem interagir separadamente ou pela navegação entre os relacionamentos pai/filho em uma hierarquia de tabelas, linhas , colunas, restrições e relacionamentos. Com isto um DataSet praticamente representa um banco de dados relacional em memória. Ponto para a ADO.NET.

II)

- Em um recordset ADO o modelo de navegação pelos dados é baseado em cursores que podem estar baseados no lado do cliente ou do servidor. Com isto você tem que trocar de lado as vezes.

- Um DataSet é um conjunto de dados representando o banco de dados em memória e off-line , com o isto os dados estão sempre disponíveis. Ponto para a ADO.NET.

III)

- ADO é baseado no modelo COM - Component Object Model - , neste modelo quando os dados são trocados entre os componentes eles precisam sofrer um processo chamado - marshaling - que envolve a copia e processamento(montagem e desmontagem) dos dados de maneira que um processo complexo é envolvido na troca de dados entre os componentes.

- Um DataSet e os componentes DataTable fazem a troca de dados remota usando XML . Os dados simplesmente são convertidos para o formato XML e transmitidos. Ponto para ADO.NET.

IV)

- Para tratar , gerenciar e transmitir dados na WEB usando ADO fatalmente passamos pela DCOM e infelizmente os roteadores e firewalls detestam DCOM ; muitos contornam o problema fazendo mirabolantes maracutaias.

- Com ADO.NET não há este problema pois ela não usa DCOM mas XML e como XML é texto os dados podem ser transmitidos e trocados ( usando serialização de componentes Datatable em XML). Ajunte a isto o fato de um DataSet ser desconectado e não ter dependêncas externas (nada de registros e instalação de componentes).Ponto para ADO.NET.

V)

- No ADO as atualizações feitas um Recordset podiam ser transmitidas de volta ao banco de dados usando o método UpdateBatch que tentava aplicar todas as alterações feitas no Recordset; o problema é que você não tinha muito controle sobre o processo.

- No ADO.NET o objeto DataAdapter possui propriedades (InserCommand,DeleteCommand,UpdateCommand e SelectCommand) que junto com outros recursos permitem um controle sobre as atualizações feitas em um DataSet com otimização de desempenho.Ponto para ADO.NET.

VI)

- Como ADO usa COM , o envio de dados via marshaling de COM limita os tipos de dados ao conjunto definido pelo modelo COM.

- ADO.NET usa XML e não existe qualquer restrição aos tipos de dados enviados.Ponto para ADO.NET.

Placar final : ADO.NET 6 x 0 ADO , isto por que não entrei em detalhes mais avançados.

Resumindo o modelo ADO.NET

Então quando você pensar em acesso a dados usando a ADO.NET você terá duas opções básicas :

1- O acesso direto a fonte de dados usando o objeto DataReader que oferece um acesso otimizado de somente leitura para frente com os dados sendo retornados pelos objetos command.

2- O acesso desconectado via cache usando o objeto DataSet em conjunto com o objeto DataAdapter que faz a ponte entre o DataSet e o Banco de dados.

Nada de Recordsets , de cursores ; nada de COM , só XML.

Em um outro artigo vamos ver as vantagens e desvantagens de cada opção. Por enquanto é só ...

José Carlos Macoratti