Aplicação completa com C#, Visual Studio e ASP.NET – Revista easy .net Magazine - Parte 5

Neste artigo vamos falar muito de ADO.NET, tanto os componentes do provider para SQL Server quanto da classe DataSet. Esta classe faz parte do grupo de componentes desconectados. Podemos comparar o DataSet ao ClientDataSet da VCL do Delphi Win32, pois permite armazenar dados em memória. Porém, de nada adianta colocarmos estes dados em memória se não persistirmos esses dados no servidor de alguma forma, visto que, após processar uma requisição, o ASP.NET destrói tudo da memória (devido a sua natureza state-less). Para isso, veremos como usar o objeto Session, que permite gerenciar uma sessão de usuário.

  Um DataSet pode conter dados vindos de praticamente qualquer banco de dados, utilizando para isso uma “ponte” através de um Managed Provider, como para o SQL Server que estamos utilizando até aqui. Assim como o ClientDataSet, um DataSet independe de fonte de dados, podendo conter dados vindos de arquivos XML, Web Services, criados somente em memória (estilo tabelas temporárias – o que faremos aqui) entre outros.

  Na verdade, quando utilizamos o SqlDataSource até aqui, fizemos uso de um DataSet por baixo (dê uma olhada na propriedade DataSourceMode do controle). Como comentei anteriormente, o SqlDataSource não faz muita coisa além de ser uma “casca fina” em cima do ADO.NET. A partir deste artigo, nós veremos como utilizar ADO.NET no “braço”, ou seja, vamos codificar. Além disso, também veremos como usar também conexões e DataReaders do ADO.NET (conectado), em vista disso, vale uma introdução à tecnologia.

Introdução ao 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). Uma importante mudança com relação ao ADO é que 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 cache 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 intercâmbio 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 Prism. 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

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 alguns Managed Providers nativos com o .NET Framework, como SQL Server Data Provider, OLE DB Data Provider e ODBC. Você utiliza o primeiro tipo quando precisar criar uma aplicação que se comunique exclusivamente com SQL Server, é o nosso caso.

O segundo tipo permite a comunicação com outros bancos de dados que tenham suporte à drivers OLE DB, como Oracle, DB2, Access etc. Você pode encontrar na internet drivers OLE DB para uma série de bancos, inclusive Firebird, 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, esta é a opção mais otimizada para trabalhar com ADO.NET, pois ninguém conhece melhor o próprio banco do que quem construiu ele, logo o provider nativo será sempre mais rápido.

Cada Managed Provider possui objetos básicos para a comunicação com um servidor de dados, por exemplo: DBConnection, DBCommand, DataReader e DataAdapter. No ADO.NET, seguindo um princípio importante da orientação a objetos, cada objeto tem uma responsabilidade bem definida e coesa; cada um desempenha uma função bem 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 cache e atualizar dados.

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ê vai usar um SqlConnection no caso do SQL Server; para um DataReader, deve-se usar o SqlDataReader.  Os objetos de acesso ao SQL Server estão disponíveis no namespace System.Data.SqlClient.

Ainda na Tabela 1, você pode observar a similaridade do ADO.NET com o dbExpress. Cada objeto no ADO.NET implementa uma interface (IDbConnection, IDbCommand, IDataReader, IDataAdapter, IDbTransaction).  Essas interfaces são implementadas por cada um dos Managed Providers. De forma semelhante, no dbExpress, cada driver deve implementar as interfaces ISQLConnection, ISQLCommand, ISQLCursor e ISQLDriver. Veja na "

ATENÇÃO! A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da Easy .net magazine ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

Saiba como acessar este post através de Créditos DevMedia:

Assinatura de Créditos – Aqui este post custa R$ 1,50
Com esse plano você compra R$ 180,00 em créditos e ganha, em média, 80% de desconto no preço do post.  
Assine agora

Plano ocasional - Aqui este post custa: R$ 2,00 (assinante) ou R$ 2,50 (não-assinante)
Você compra um mínimo de R$ 60,00 em créditos e ganha, em média, 50% de desconto no preço do post.  
Compre agora

Plano conveniência – Neste plano este post custa R$ 5,00
Neste plano você compra somente um post, pagando seu preço sem desconto.  
Compre agora