Conceitos básicos

Os componentes tradicionais para acesso a banco de dados, como o ODBC, ADO, BDE (da Borland), foram projetados para trabalhar em rede local, no modelo cliente/servidor. Neste modelo, a aplicação se conecta ao SGDB e realiza suas operações com dados, através de instruções SQL ou executando stored procedures. Normalmente, esta conexão permanece aberta até que a aplicação seja encerrada, pois ficar abrindo e fechando conexões penaliza o desempenho da aplicação. Este método funciona muito bem, mas trás consigo desvantagens, como por exemplo, quando dezenas ou centenas de usuários usam a aplicação simultaneamente e o SGDB tem que gerenciar todas estas conexões, o que normalmente acaba gerando uma sobrecarga no banco e penalizando o desempenho. Sem contar que os SGDB’s tem limites de conexões simultâneas e cada conexão adicional representa um grande trabalho de gerenciamento a mais, podendo até mesmo, em certos SGDB’s, causar corrupção de dados.

A coisa se complica mais ainda se utilizarmos este método para aplicações executando na Web, por vários motivos:
•    Uma conexão com a Internet, por mais rápida que seja, ainda é muito mais lenta que uma conexão local (pelo menos até agora), o que significa que a velocidade de acesso a dados fica muito lenta;
•    Por melhor que seja o tipo da conexão, ela pode cair a qualquer momento e ser restabelecida em seguida, e neste caso sua aplicação teria que ser reinicializada, e haveria uma grande chance dos dados serem corrompidos;
•    Muita gente, principalmente usuários de notebooks em trânsito ou de dispositivos móveis, usa conexões através de linhas discadas ou celular, que consomem pulsos, e manter uma conexão por um longo período pode significar um enorme gasto, além da instabilidade da conexão;
•    Na Web, é impossível saber e controlar a quantidade de usuários que estão utilizando sua aplicação, e consequentemente acessando o banco de dados, e isto pode simplesmente extrapolar os limites do SGDB ou até mesmo causar um travamento no sistema.

A plataforma .Net, ao contrário de ferramentas tradicionais, foi criada visando não só aplicações locais, mas também a Internet e os dispositivos móveis (chamados smart devices). Ela trouxe consigo uma forma única e padronizada de acesso a dados, chamada ADO.Net. Apesar do nome indicar uma evolução do ADO tradicional, o ADO.Net praticamente não tem nada a ver com ele, a não ser em pequenos detalhes e nem sequer utiliza a tecnologia Active-X, pois foi totalmente construído sob plataforma .Net. O ADO.Net é extremamente eficiente e flexível, e introduziu o conceito de arquitetura de dados desconectada. Na verdade, no ADO tradicional você já podia fazer isto, mas o fato de ficar abrindo e fechando conexões a todo momento tem um custo enorme pro banco de dados, e consequentemente para o desempenho do sistema, por isto não era utilizada.

O ADO.Net suporta comunicação com fontes de dados tanto ODBC como OLE-DB, mas também oferece a opção de usar data providers específicos para bancos de dados. Estes data providers, por se comunicarem diretamente com o SGDB, sem utilizar as camadas ODBC ou OLE-DB, trazem um grande ganho de performance. A plataforma .Net já vem com os data providers para ODBC, OLE-DB, SQL Server e Oracle. Além destes, vários fabricantes de bancos de dados fornecem seus data provider específicos, como o mySQL, Firebird, DB2 e vários outros.

Nos componentes tradicionais de acesso a dados, você faz uma conexão com o SGBD e usa esta conexão para interagir com o banco. A conexão permanece aberta, mesmo quando você não está usando seus serviços. Isto normalmente gasta recursos valiosos e caros do SGDB, pois na maioria das vezes sua aplicação está apenas consultando e exibindo dados.

O ADO.Net resolve este problema mantendo e gerenciando um pool de conexões. Desta forma, na primeira vez que você faz a conexão com o SGDB, é feita realmente uma conexão tradicional, física, o que leva algum tempo. Mas quando você fecha esta conexão em seu programa, o ADO.Net faz uma espécie de cache local, ou seja, a conexão é fechada logicamente mas permanece fisicamente aberta. Desta forma, quando você abre novamente uma conexão com as mesmas características, o ADO.Net verifica em seu pool de conexões se existe alguma disponível com as mesmas características e a reutiliza, sem refazer a conexão fisicamente. E isto representa um enorme ganho de desempenho.

No método tradicional de acesso a SGDB’s, você envia um comando SQL ao banco de dados e obtém um conjunto de registros (ou recordset) como resultado, que está disponível apenas enquanto você mantiver a conexão aberta. O ADO.Net utiliza uma estrutura chamada DataSet, onde sua aplicação se conecta automaticamente ao SGDB quando precisa executar uma instrução SQL e imediatamente após receber o resultado e armazená-lo no DataSet, se desconecta. Este mecanismo do ADO.Net é chamado de arquitetura de dados desconectada e é muito parecido com os serviços sem conexão do HTTP na Internet.

Um RecordSet tradicional é apenas um conjunto de registros, resultado de uma instrução SQL, mas o DataSet vai muito além disto. Ele praticamente é um banco de dados completo que fica na memória da máquina cliente, podendo conter várias tabelas, índices, campos, relacionamentos, etc.

Outro detalhe importante é que os componentes tradicionais de acesso a dados usam o COM/COM+ para se comunicarem, e são facilmente barrados por firewalls, a não ser que o administrador da rede abra as portas necessárias para que eles se comuniquem. O ADO.Net, ao contrário, usa XML sobre o protocolo SOAP para armazenar e fazer todo o tráfego de dados, e o XML utiliza a porta 80, ou seja, a porta HTTP, que está sempre aberta e não é bloqueda por firewalls.

Um dos grandes objetivos na construção do ADO.Net foi aumentar o desempenho de acesso a dados o máximo possível. Por isto ele apresenta outras características interessantes, como o bulk insert, que permite que você adicione várias linhas (ou registros) ao banco de dados numa única operação, ao invés do tradicional método de inserir uma linha por vez. Outro exemplo é a capacidade de ser notificado quando acontecem alterações nos dados, indicando que somente neste momento o cache local (DataSet) deve ser atualizado. O recurso MARS (Multiple Active Result Sets ou múltiplos conjuntos de resultados ativos) permite executar várias consultas de uma só vez, e receber uma série de resultados. Você também pode optar por executar outras tarefas numa atualização grande e demorada do banco de dados, usando o recurso de disparar um comando assíncrono. Além disto, você pode escrever código de acesso a SGDB’s independente da fonte de dados, o que é especialmente útil quando seu sistema deve ser compatível com diversos bancos de dados.

Por fim, o ADO.Net também fornece os serviços de acesso a dados tradicionais, orientados a conexão.

Arquitetura básica do ADO.NET

Observando a figura acima, podemos ver claramente as duas porções principais do ADO.Net : o quadro a esquerda representa a parte ou os objetos conectados (.Net Data Provider), que tem contato direto com a fonte de dados e a figura a direita representa o objeto desconectado (DataSet), que transforma todas suas informações em XML. Vamos a uma primeira explicação:

Data Provider: o objeto conectado

A parte conectada representa os objetos que tem uma conexão disponível para trabalhar e interagir diretamente com a fonte de dados. Os principais objetos desta parte do ADO.Net são :
    Connection: Este é o objeto que permite estabelecer uma conexão com a fonte da dados. Dependendo do Data Provider, estes objetos se encarregam de fazer um pool de conexões físicas. A classe básica é a DbConection, com as especializações OdbcConnection, OleDbConnection, SqlConnection e OracleConnection, além da interface genéria IdbConnection.

    Transaction: muitas vezes é necessário executar um grupo de comandos juntos, numa operação atômica, do tipo execute tudo ou nada. Um exemplo clássico é uma transação bancária, onde não pode haver um crédito sem o débito correspondente. Objetos Transaction permitem agrupar estes comandos num conjunto único e executar a transação inteira, ou desfazê-la totalmente, se algo sair errado. Sua classe básica é a DbTransaction, com as especializações OdbcTransaction, OleDbTransaction, SqlTransaction e OracleTransaction, além da interface genérica IdbTransaction.

    Command: Este objeto representa um comando executável pela fonte de dados, que pode ou não retornar algum resultado. Objetos Command aceitam qualquer sentença SQL válida para o banco de dados, permitindo consultar, atualizar, inserir e excluir linhas e podem inclusive serem usados para manipular a estrutura de uma tabela. A classe básica é a DbCommand, com as especializações OdbcCommand, OleDbCommand, SqlCommand e OracleCommand, além da interface genérica IdbCommand.

    DataReader: Este objeto faz uma leitura no banco de dados na forma somente para a frente e somente leitura, numa velocidade extremamente rápida. Sua classe principal é a DbDataReader, com as especializações OdbcDataReader, OleDbDataReader, SqlDataReader e OracleDataReader, além das interfaces genéricas IdataReader e IdataRecord.

    DataAdapter: este objeto age como uma ponte entre o modo conectado e desconectado do ADO.Net. Ele estabelece uma conexão com o banco de dados, ou pode receber uma conexão já feita, tem informações suficientes especificadas nele mesmo que lhe permitem entender dados armazenados em objetos desconectados e agir sobre o banco de dados de uma maneira pré-estabelecida. Sua classe básica é a DbDataAdapter com as especializações OdbcDataAdapter, OleDbDataAdapter, SqlDataAdapter e OracleDataAdapter, além da interface genérica IdbDataAdapter. Um DataAdapter contém quatro propriedades básicas, representando as operações CRUD, que contém as respectivas sentenças SQL a serem executadas. Observe que estas sentenças são específicas para a sintaxe SQL de cada DataProvider. Por exemplo, parâmetros são especificados com o símbolo “@” no SQL Server, mas em ODBC é usado o símbolo “?”.
o    SelectCommand: propriedade que contém a sentença SQL do comando Select;
o    InsertCommand: propriedade que contém a sentença SQL do comando Insert;
o    UpdateCommand: propriedade que contém a sentença SQL do comando Update;
o    DeleteCommand: propriedade que contém a sentença SQL do comando Delete;

DataSet: o objeto desconectado
Aplicações com a filosofia de banco de dados desconectado, se conectam ao banco o mais tarde possível e se desconectam o mais cedo possível, ou seja, ficam conectadas o mínimo de tempo necessário para a atualização das informações. Para evitar perda de desempenho, pois a tarefa de conexão e desconexão é pesada para o SGDB, o ADO.Net mantém um pool de conexões, ou seja, mesmo quando seu sistema fecha a conexão, o ADO.Net a mantém aberta por um tempo, assim se logo em seguida for necessária uma conexão do mesmo tipo, será usada uma das que estiverem disponíveis neste pool, e não criada uma nova. Os principais objetos da parte desconectada do ADO.Net são:

    DataSet: o DataSet é o núcleo de todo o sistema de acesso a dados desconectado do ADO.Net. Ele é completamente diferente do antigo RecordSet, do ADO tradicional, que comprendia apenas um conjunto de registros. A melhor maneira de visualizar um DataSet é pensar num mini-SGDB completo, com tabelas, campos, índices, relacionamentos, etc, armazenado na memória local. Obviamente ele não substitui um SGDB, isto é apenas uma forma de entendê-lo. O DataSet está na classe System.Data.DataSet, ou seja, acima de qualquer Data Provider, o que o torna independente de qualquer fonte de dados. Pode, inclusive, haver várias fontes de dados diferentes num único DataSet. Você também pode imaginar um DataSet como uma coleção de DataTables e DataRelations.

o    DataTable: é a representação de uma tabela de banco de dados no DataSet. Ele contém DataColumns (o equivalente de colunas) e DataRows (o equivalente de linhas).

    DataRow: uma das propriedades de um DataTable são as Rows, do tipo DataRowCollection, que representa uma coleção numerada de objetos DataRow. A medida que um DataTable é preenchido com dados, a DataRowCollection adiciona novos objetos DataRow a si mesma. Ou seja, um DataRow é o equivalente de uma linha numa tabela de banco de dados.

    DataColumn: um DataTable também contém a propriedade Column, do tipo DataColumnCollection e essencialmente representa a estrutura do DataTable. Um DataColumn é o equivalente a uma coluna de uma tabela de banco de dados.

    Constraint: esta é outra propriedade do DataTable, do tipo ConstraintsCollection. Ela permite criar objetos do tipo ForeignKeyConstraint (para chaves estrangeiras) ou UniqueConstraint (para chaves exclusivas) e associar várias colunas a certas condições, criando filtros que definem quais dados do DataTable devem satisfazer estas condições antes de fazer parte dele.

o    DataView: é um objeto que corresponde a uma view num banco de dados. Um DataView permite que você crie uma “view” de um DataTable e obtenha um subconjunto de dados, baseados nas condições especificadas na propriedade Filter.

o    DataRelation: um DataSet, como um banco de dados, pode conter várias tabelas relacionadas. Objetos DataRelation especificam relações entre várias tabelas, permitindo tanto a validação de dados como a navegação entre tabelas tipo pai-filho, em vários DataTables. Seu uso mais comum é a especificação de chaves-estrangeiras entre duas tabelas. A diferença entre a ForeignKeyConstraint e a DataRelation é que esta última, além de validar os dados, fornece um mecanismo de navegação entre linhas tipo pai-filho num DataSet.

Na figura abaixo, temos a representação visual de um DataSet e seus objetos:

Aqui podemos ver que um DataSet é formado por diversas coleções, onde as mais comuns são a DataTableCollection, que contém cada DataTable (tabela); por sua vez, cada DataTable contém uma DataRowCollection (com as linhas da tabela) e um objeto DataRow para cada linha; também contém a DataColumnCollection (colunas), e um objeto DataColumn para cada coluna; além disto, cada DataTable também pode conter um objeto DataView e PrimaryKey, entre outros.
Abraços

Posts Relacionados:

Related Posts with Thumbnails