VB.NET 2005 -
Migrando do ADO para ADO.NET 2.0 VB.NET 2005 -
Migrando do ADO para ADO.NET 2.0
Creio que a intenção da Microsoft ao criar a ADO.NET foi tentar maximizar a escalabilidade das aplicações Windows Forms e Web Forms que fazem um intensivo uso e/ou acesso/processamento de dados.
Isto pode não ter muito sentido se o seu projeto envolve uma aplicação cliente com alguns formulários Windows que retornam e atualizam dados em algumas tabelas em um único banco de dados. Já para projetos como grandes portais ou sites web com grande volume de tráfico, onde, a habilidade de poder mudar para um processador mais potente no mesmo servidor ou aumentar a quantidade de servidores para poder processar e gerenciar um volume maior de dados, pode significar a expansão ou a falência, o fato de ter uma aplicação com grande escalabilidade é de primordial importância estratégica.
Possuir um código ADO.NET gerenciado que minimiza a duração do tempo de acesso e a concorrência aos dados em conexões com servidores de banco de dados e que utilizam testes de concorrência otimista para atualizar tabelas, pode ser a chave para alcançar a tal escalabilidade em projetos com intensivo acesso a dados.
Vamos começar dando uma espiada no principal namespace usado para acesso a dados do .NET Framework 2.0 : o namespace System.Data.
O namespace System.Data do .NET Framework 2.0 contém todas os namespaces, classes, interfaces , enumerations e delegates da ADO.NET 2.0. Usando o Object Browser (Menu->View) do VB 2005 podemos observar o namespace Data, conforme figura abaixo:
 |
O namespace System.Data
fornece acesso as classes que representam a arquitetura ADO.NET. ADO.NET permite a criação de componentes que gerenciam de forma eficiente dados de múltiplas fontes de dados. |
Além do namespace Data podemos ver também outros namespaces muito usados para acesso a dados que já estão presentes no ADO.NET da Framework 2.0.(Ex: System.Data.OleDb, System.Data.SqlClient, System.Data.Odbc, System.Data.OracleClient, etc.)
Vejamos mais de perto o namespace System.Data.OleDb que é usado para acessar muitas fontes de dados, dentre elas o Microsoft Access.
 |
A hierarquia de namespaces para os objetos
fornecedores de dados gerenciados (1)OleDbConnection e (2)OleDbCommand
é a seguinte: (1) (2) Onde os namespaces em negritos são os novos objetos da ADO.NET 2.0 System.Data.Common - Fornece classes que todo os provedores compartilham, tais como DBConnection e DbCommand System.Data.Common.DBConnection - Fornece classes herdaveis para uma tecnologia especifica e fornecedores específicos de data providers.
|
Mas onde entra a ADO - Activex Data Object - nesta história ? É simples; os objetos OleDbConnection e OleDbCommand correspondem aos já conhecidos ADODB.Connection e ADODB.Command.
Os provedores de dados gerenciados da ADO.NET 2.0 e seus objetos correspondentes forma a espinha dorsal do acesso a dados da plataforma .NET. Eles são uma abstração a camada de serviço de dados e são similares em conceito as classes ADODB do ActiveX Data Object - ADO, que suportam somente os provedores OLE DB.
Os objetos de dados básicos da ADO.NET e seu relacionamento com objetos ADODB
Os objetos de dados básicos da ADO.NET que possuem objetos ADODB correspondentes são :
1- Objeto Connection - Define o provedor de dados, a instância do gerenciador de dados, as credenciais de segurança do banco de dados e outras propriedades de conexão relacionadas.
O código do VB2005 para criar uma conexão .NET é muito similar ao código usado no VB 6 para criar um objeto ADODB.Connection.
2- Objeto Command - Executa instruções SQL em lote ou procedimentos armazenados sobre uma conexão aberta. Os objetos Command podem retornar um ou mais conjunto de resultados, uma única linha, um único valor escalar, um objeto XmlDataReader ou um valor para RowsAffected em atualizações de dados. No ADO.NET o objeto Command não é opcional como quando abrimos objetos ADODB.Recordsets de um ADODB.Connection. Os objetos Command suportam uma coleção de parâmetros (parameters) para executar consultas parametrizadas ou procedimentos armazenados. O relacionamento entre os parâmetros ADODB e ADO.NET e os comandos é idêntico.
3- Objeto DataReader -Retornam um ou mais de um(SQL Server) conjunto de dados somente-leitura com acesso somente-para-frente através da execução de uma instrução SQL ou procedimento armazenado. O código VB.NET para criação e execução de um DataReader a partir de um objeto Command em um objeto Connection é similar aquele usado para criar um objeto ADODB Recordset padrão sem cursor a partir de um objeto ADODB.Command.(A diferença é que você não pode salvar um conjunto de dados do DataReader para um arquivo local e reabrí-lo com cursor do lado do cliente através dos métodos Save e Open como faz com objeto ADODB.Recordset.)
4- Objeto XmlReader - Consome um fluxo que contém documentos XML bem-formados. São equivalentes aos cursores somente-leitura e somente-para-frente em documentos XML e correspondem ao objeto ADODB.Stream retornado pelo provedor SQLXML 3.0/SQLXMLOLEDB.
Para facilitar a visualização abaixo temos a figura que ilustra o relacionamento entre os objetos ADO.NET Connection, Command, Parameter, DataReader e XmlReader:
 |
Parecido não é mesmo ???
Os Objetos dataset tipados da ADO.NET
O objeto DataSet é único na ADO.NET e utilizar DataSets tipados para retornar e atualizar dados em tabelas relacionais é um dos métodos preferidos. Você cria um DataSet tipado, que é definido por um esquema XML e implementado por uma grande de código gerado automaticamente pelo VB2005, usando os assistentes do VB2005. Os DataSets não tipados são objetos em tempo de execução que você cria via código sem a ajuda destes assistentes.
Os objetos DataSet não possuem correspondentes no de objetos ADODB da ADO; mas as classes do objeto DataSet se comportam de modo similar aos Recordsets desconectados da ADO da seguinte forma:
Eles abrem uma conexão, retornam e guardam em cache os dados para edição, e então fecham a conexão.
Eles efetuam a vinculação com controles Windows Forms simples(TextBox) e complexos(Grid) para edição.
Eles permitem editar localmente os dados em cache enquanto a conexão esta fechada
Eles podem ser salvos em arquivos locais e reabertos para edição
Eles permitem reabrir a conexão e atualizar as tabelas em lotes
Eles implementam a concorrência otimista para atualizar tabelas.
Vamos falar agora das principais diferenças entre os dois modelos para que ninguém ache que é TUDO igual:
Um DataSet é constituído da cópia de um ou mais conjunto de registros - chamados DataTable - selecionados a partir de uma ou mais tabelas. Um Recordset é um único conjunto de registros que pode representar uma visão de um ou mais tabelas relacionadas.
Ao persistir um DataSet você serializa os registros das DataTables para um modelo XML hierárquico e salva-o em arquivos locais do sistema. Os Recordsets desconectados armazenam os dados localmente em arquivos planos padrão XML>
As DataTables geralmente são referenciadas pela chave primária/chave estrangeira e relacionamentos.
Você pode criar DataTables a partir das tabelas base para qualquer banco de dados acessível.
Você pode criar DataTables a partir de documentos estruturados no padrão XML.
A figura abaixo compara os objetos requeridos para atualizar
Recordsets ADODB com DataSets tipados da ADO.NET 1.x e 2.0.
(Os novos componentes da ADO.NET 2.0 estão coloridos de amarelo)
Como podes ver, mesmo que existam diferenças , a curva de aprendizado para quem já conhece ADO é menor pois já esta familiarizado com muitos conceitos usados na ADO.NET.
Aguardo você no próximo artigo VB.NET... 
José Carlos Macoratti