ADO.NET para o Programador ADO

Dino Esposito
Microsoft Corporation

Março de 2001

Resumo: Este artigo discute o modo ADO.NET de efetuar operações básicas de banco de dados e quando usar o ADO.NET ao invés do ADO. (10 páginas impressas)

Conteúdo

Acesso a Dados Após o .NET
Lendo Dados
DataSet, DataTable e Recordset
Traduzindo Código Existente
Atualizando Dados
O Suporte Estendido para XML
Resumo

ADO.NET é a mais recente de uma longa linha de tecnologias de acesso a banco de dados que começou com a interface de programação de aplicação (API) do Open Database Connectivity (ODBC) há vários anos atrás. Com o tempo, várias coisas interessantes aconteceram. Por exemplo, COM aterrizou no território de banco de dados e iniciou um processo de colonização que culminou com o OLE DB. Em seguida,  ActiveX® Data Objects (ADO)— a grosso modo uma versão automatizada do OLE DB—foi eleito para governar a comunidade Visual Basic® e ASP dos desenvolvedores de bancos de dados baseados em Windows®.

Com o .NET, a Microsoft está oferecendo um framework de propósito geral —a Framework Class Library—que se expandirá para cobrir todas as API Windows existentes e mais. Em particular, ela incluirá várias bibliotecas usadas freqüentemente agora disponíveis através de objetos COM separados. Entre estes, você encontra os modelos de objeto XML e ADO que foram integrados em uma sub-árvore de classes chamada ADO.NET.

ADO.NET vem a ser o substrato que formará a base das aplicações .NET sensíveis a dados. Diferente do ADO, o ADO.NET foi projetado propositadamente de acordo com orientações mais gerais e menos orientadas a banco de dados. ADO.NET reúne todas as classes que permitem tratamento de dados. Tais classes representam objetos container de dados que possuem capacidades típicas de banco de dados — indexação, classificação, modos de exibição. Embora o ADO.NET seja a solução definitiva para aplicações de banco de dados .NET, ele apresenta um design genérico que não é centrado em banco de dados como o modelo ADO.

ADO.NET é totalmente diferente do  ADO. Ele é um novo modelo de programação de acesso a dados que requer entendimento completo, comprometimento e um mindset diferente. Entretanto, após começar a usar o ADO.NET, você perceberá que quaisquer habilidades ADO que você possui são de tremenda ajuda na construção de aplicações efetivas e na resolução de problemas antigos de uma forma diferente, porém mais elegante e consistente.

A partir deste ponto, eu me concentrarei na forma ADO.NET de efetuar operações básicas de banco de dados. Eu deixarei claro quando ADO.NET é uma escolha melhor do que o ADO, assim como quando é melhor utilizar o ADO. ADO.NET não é o ADO adaptado para a infra-estrutura .NET. Isto se torna aparente quando você olha para o ADO.NET em termos de sintaxe, projeto de código e migração.

Acesso a Dados Após o .NET

O acesso a fontes de dados no ADO.NET é regido por provedores gerenciados. Funcionalmente falando, um provedor gerenciado é bem parecido com um provedor OLE DB com duas diferenças importantes. Primeiro, eles trabalham no ambiente .NET e recuperam e expõem dados através de classes .NET tais como DataReader e DataTable. Segundo, sua arquitetura é mais simples pois está otimizada para o .NET.

Atualmente, ADO.NET vem em dois sabores de provedores gerenciados: um para o SQL Server™ 7.0 e superior e outro para todos os  outros provedores OLE DB que você possa ter instalado. As classes que você utiliza em ambos os casos são diferentes, mas seguem uma convenção de nomes similar. Os nomes são os mesmos exceto para os prefixos. O prefixo é SQL no primeiro caso e ADO no último.

Você deve usar classes SQL para acessar tabelas do SQL Server pois elas acessam diretamente a API interna do banco de dados, pulando o nível intermediário representado pelo provedor OLE DB. Classes ADO são uma interface .NET no topo dos provedores OLE DB e utilizam a ponte COM Interop para fazer o trabalho.

Para aprender um pouco mais sobre objetos ADO.NET, veja o artigo de Omri Gazitt, Introduzindo ADO+: Serviço de Acesso a Dados para o Framework Microsoft .NET, e meu artigo ADO+ Direciona a Evolução das Espécies de Dados. O primeiro é mais técnico e proporciona uma visão geral detalhada de alto nível do modelo de programação ADO.NET. O segundo é direcionado para a explicação da motivação para o ADO.NET e como ele se relaciona com XML, script e outras tecnologias.

Lendo Dados

Uma aplicação ADO.NET que precisa ler alguns dados de uma fonte de dados deve começar pela criação de um objeto de conexão. Ele pode ser o SQLConnection ou ADOConnection dependendo do provedor alvo. Tenha em mente que, embora não seja recomendado, você pode usar classes ADO.NET para efetuar conexão a um banco de dados SQL Server. O único ponto negativo é que seu código passa por uma camada de código extra desnecessária. Ele chama o provedor gerenciado do ADO, que por sua vez chama o provedor  OLE DB do SQL Server. O provedor gerenciado do SQL Server, no entanto, vai direto aos dados como um provedor OLE DB faria.

Uma diferença significativa entre objetos de conexão ADO e ADO.NET reside no fato de que a conexão ADO.NET não suporta a propriedade CursorLocation. Note que isto não é bug de documentação, e sim um problema de projeto passível de debate. Para reforçar sua visão básica do mundo centrada em dados, ADO.NET não possui implementação explícita de cursores.

No ADO, você estava acostumado a utilizar cursores para extrair registros de um banco de dados, ou de qualquer outra fonte de dados compatível com OLE DB. Você podia escolher entre cursores cliente ou servidor e, dependendo da sua escolha, entre alguns tipos de cursor pré definidos. ADO.NET tende a abstrair a partir da fonte de dados e proporciona uma nova interface de programação para leitura e análise de dados.

No ADO, você cria um objeto Recordset especificando uma conexão e um texto de comando. O Recordset possui certas políticas para localização de cursor e tipo. Para ler dados você pode fazer o seguinte:

·         Criar uma cópia estática em memória dos registros selecionados e processá-los de acordo com sua vontade durante sua desconexão da fonte de dados. ADO chama isto de um cursor estático.

 

·         Percorrer os dados através de um rápido cursor somente de leitura e forward-only que trabalha sobre um instantâneo estático dos registros. ADO chama isto de um cursor somente de leitura.

 

·         Acessar dados através de dois tipos de cursores do lado servidor que precisam de uma conexão excelente mas permitem que você detecte, em níveis diferentes, alterações sendo feitas por outros usuários conectados. ADO chama estes cursores de keyset e cursores dinâmicos.

As primeiras duas opções são similares pelo fato de que ambas trabalham em recordsets desconectados e lêem informação a partir de um cache no lado cliente. Além disso, estas duas opções provaram ser as mais freqüentemente utilizadas em contextos orientados a Web e para novos sistemas n-tier.

No ADO, todas as opções acima são mapeadas para um tipo diferente de cursor. Como você verá mais tarde neste documento, ADO.NET é bem diferente, mas você não perderá qualquer uma das capacidades que você tinha com o ADO. Em contraste, o seu código abstrairá das fontes de dados reais e sua  mídia de armazenamento física e formato.

ADO.NET disponibiliza dois objetos para manipular dados extraídos de uma fonte de dados. São eles os objetos DataSet e DataReader. O primeiro é um cache em memória de registros que você pode visitar em qualquer direção e modificar de acordo com sua vontade. O segundo é um objeto altamente otimizado projetado para percorrer registros somente de leitura em uma maneira forward-only. Note que o DataSet parece com um cursor estático enquanto o objeto DataReader é a contraparte .NET direta do cursor somente de leitura do ADO.

No ADO.NET não há suporte para cursores no lado servidor. Entretanto, isto não significa que você não pode utilizá-los. O que você tem a fazer é importar a biblioteca de tipos ADO  para o .NET. Isto é tão fácil quanto efetuar o clique do botão direito do mouse no nó References na janela projeto. Após fazer isto, você pode começar a usar projetos ADO nativos nas suas aplicações.

Embora eu pessoalmente recomende que você comece a pensar em reescrever suas aplicações existentes com o.NET em mente, eu reconheço que portar para o .NET não é uma decisão fácil de tomar. Uma importação completa do ADO talvez seja o primeiro passo prático com .NET sem investir muito tempo e recursos. Entretanto, tenha em mente que este é apenas o primeiro passo de um caminho mais longo. De forma alguma este deve ser o único passo a tomar em direção ao .NET. O verdadeiro valor adicional do .NET vem de uma interface de programação uniforme e consistente e do amplo uso das classes nativas. A importação de bibliotecas de tipos COM é suportada, mas não encorajada, e somente é razoável como uma solução de curto prazo ou um passo intermediário.

Ao pensar no ADO.NET, leve em consideração cuidadosamente o fato de que o ADO.NET unifica a interface de programação para classes de container de dados. Qualquer que seja o tipo de aplicação que você vai escrever—Windows Form, Web Form ou Web Service—você trata os dados através dos mesmos conjuntos de classes. Seja a fonte de dados no back-end um banco de dados SQL Server, um provedor OLE DB, um arquivo XML ou um array, você percorre e trata o seu conteúdo através dos mesmos métodos e propriedades.

Figura 1. Menu Solution Explorer

Se você aderir ao ADO no mundo .NET, esteja preparado para enfrentar alguns efeitos colaterais como o código extra necessário para tornar os recordsets usáveis a partir de controles data-bound.

DataSet, DataTable e Recordset

O ADO.NET não possui nenhum contraparte direto para o objeto Recordset. O mais próximo é o objeto DataTable. Embora eles possuam um conjunto de funcionalidades quase idêntico, eles têm um papel diferente nos seus respectivos frameworks.

O Recordset é um enorme objeto que possui muitas das capacidades ADO, mas ainda falha em algumas áreas. Ele é bom em muitas coisas—ele pode ser criado, ele trabalha desconectado, ele é rico em funcionalidades—mas poderia ser melhorado em algumas áreas. Por exemplo, é pesado efetuar serialização sobre uma rede devido a sua natureza COM inerente, ele é um objeto binário difícil de compartilhar entre módulos rodando em plataformas diferentes e ele não pode penetrar firewalls. Além disso, ele representa uma única tabela de registros. Se esta tabela é o resultado de um ou mais JOINs, pode ser difícil atualizar as fontes de dados originais. Quando você tenta reconciliar seu recordset desconectado com a fonte de dados original, ele funciona desde que a fonte de dados entenda SQL. Entretanto, é bem provável que seu recordset tenha sido criado por um provedor não SQL.

No ADO.NET, toda a funcionalidade do Recordset do ADO foi dividida em alguns objetos mais simples —um dos quais é o DataReader. O DataReader imita o comportamento de um cursor rápido, somente de leitura e forward-only.

O DataTable é um objeto simples que representa uma fonte de dados. Você pode fabricar manualmente um DataTable, ou você pode também preenchê-lo automaticamente por comandos DataSet. O DataTable não sabe nada sobre as origens dos dados que ele contém. Ele permite a você manipular dados na memória e fazer coisas tais como navegar, classificar, editar, aplicar filtros, criar modos de exibição e mais.

O objeto DataSet é algo para o qual o ADO não tem contraparte. Ele é uma classe container de dados e é o objeto chave para realizar a abstração de dados do ADO.NET. O DataSet agrupa um ou mais objetos DataTable. O DataTable expõe seu conteúdo através de coleções genéricas como linhas e colunas. Quando você tenta ler a partir de uma tabela de dados, você deve passar através de duas camadas diferentes de objeto: DataTableMapping e DataView.

O objeto DataTableMapping contém a descrição de um mapeamento entre colunas de dados em uma fonte de dados e um objeto DataTable. Esta classe é usada pelo objeto DataSetCommand na população de um DataSet. Ele mantém o link entre colunas abstratas no conjunto de dados e colunas físicas na fonte de dados.

Uma visão da tabela é criada através do objeto DataView. Ele representa uma visão customizada do DataTable e pode ser ligado a controles especializados tais como o grid de dados em Windows Forms e Web Forms. Este objeto é o equivalente em memória do comando SQL CREATE VIEW.

Todas as tabelas em um DataSet podem ser relacionadas através de um campo comum. O relacionamento é gerenciado por um objeto DataRelation. Isto parece com o formato de dados ADO mas com uma diferença importante. Não há necessidade de lidar com a linguagem de formato de dados e você acaba tendo uma arquitetura extremamente flexível. O modelo de navegação ADO.NET permite que você se mova facilmente da linha mestre em uma tabela para todas as suas linhas filho.

O objeto DataRelation é um contraparte em memória do comando JOIN e é útil na implementação de relações pais/filho envolvendo colunas que possuem o mesmo tipo de dados. Uma vez que o relacionamento tenha sido definido, qualquer alteração que possa quebrar o relacionamento não é permitida e origina uma exceção de runtime. Visões e relações são dois métodos para implementar esquemas mestre/detalhe. Tenha em mente que uma visão é apenas uma máscara colocada nos registros, sendo que uma relação é um link dinâmico definido entre uma ou mais colunas de duas tabelas, e com relações para as quais você não tem nenhuma forma de alterar a ordem ou definir condições.

Se seu código precisa de relacionamento de chave externa 1:1 e você não altera os dados, então é melhor utilizar comandos JOIN simples. Se você precisa de capacidades de filtro extras, você deveria partir para visões customizadas do ADO.NET.

Traduzindo Código Existente

Existem muitas páginas ASP por aí usando objetos ADO para extrair dados. Vamos rever alguns cenários típicos que você pode enfrentar em um futuro próximo ao tratar do porte ou adaptação do seu código.

Se você possui páginas ASP que geram relatórios a partir de um único recordset, o objeto DataReader é o seu melhor amigo.
Você navega através dele e ele emite a página.

String strConn, strCmd;

strConn = "DATABASE=MyAgenda;SERVER=localhost;UID=sa;PWD=;";

strCmd = "Select * From Names where ID=" + contactID.Text;

SQLConnection oCN = new SQLConnection(strConn);

SQLCommand oCMD = new SQLCommand(strCmd, oCN);

oCN.Open();

SQLDataReader dr;

oCMD.Execute(out dr);

while (dr.Read()) {

// Use dr.GetString(index) or

// dr["field name"] to Response.Write data

}

Você também pode usar a propriedade HasMoreRows  para verificar rapidamente se o DataReader está vazio. Se você somente tem que passar por vários registros, nada é melhor e mais rápido do que o DataReader. Isto ainda é verdade se você tem que procurar um único registro. O conteúdo do DataReader não pode ser editado, mas você pode mover este conteúdo para um objeto mais gerenciável—por exemplo o DataTable ou um ou mais objetos DataRow.

O DataReader deixa de ser a ferramenta apropriada quando você precisa tratar relacionamentos complexos entre tabelas e registros. No ADO, você sempre acaba tendo que trabalhar com recordsets. Quanto mais articulado seu modelo de dados, mais complexos os comandos SQL. O modelo de navegação permanece seqüencial e você sempre termina fazendo caching de mais dados do que o necessário. Objetos DataSet e DataRelation são o apoio deste tipo de modelo de relacionamento de tabela.

Para gerenciar relacionamentos pai/filho, o ADO também organiza o mecanismo de modelagem de dados. Funcionalmente falando, modelagem de dados e relacionamentos ADO.NET são a mesma coisa. Entretanto, em termos de projeto, eles tem bem pouco em comum. Recordsets modelados incluem toda a informação em um único objeto tabular. Relações ADO.NET são links dinâmicos que você pode estabelecer a qualquer momento entre duas tabelas de dados. O ADO se apóia no provedor de serviço Shaping OLE DB e apresenta uma linguagem específica como o SQL para criar um recordset hierárquico na execução de um único comando ADO.

No ADO.NET, cada objeto envolvido no relacionamento é sempre visto como um indivíduo. A própria relação é exposta como um objeto e recebe certas orientações de comportamento. Por exemplo, um objeto DataRelation pode encadear alterações a partir de linhas pai até linhas filho. Você faz isto incluindo um objeto ForeignKeyConstraint a coleções de Restrições do DataTable. O objeto ForeignKeyConstraint representa uma restrição reforçada em um conjunto de colunas agrupadas através de um relacionamento de chave externa quando um valor ou uma linha é eliminado ou atualizado. Como mencionado anteriormente, uma vez que o relacionamento esteja definido, e até que ele seja terminado via programação, você não pode inserir alterações que poderiam quebrá-lo.

Em adição, relações não são transitivas. Você pode definir duas relações diferentes entre, digamos, Consumidores e Pedidos e Pedidos e Produtos. Entretanto, ao navegar pelos pedidos de um determinado consumidor você não pode pular de um pedido para o conjunto relacionado de linhas de produto. Ao invés disto, você tem que abrir a relação Pedidos/Produtos separadamente, localizar o pedido que você precisa e então solicitar as linhas relacionadas. É por isso que algumas vezes relacionamentos 1:1 são tratados de forma melhor através de antigos comandos JOIN do SQL.

Precisa armazenar registros no objeto ASP Session? Com o ADO.NET e o objeto DataSet, você pode fazer isto de forma segura sem incorrer nos efeitos desagradáveis discutidos em "Armazenando um Recordset ADO em GIT pode Causar uma Violação de Acesso" (http://support.microsoft.com/support/kb/articles/Q249/1/75.ASP), e sem ter que lidar com afinidade da thread.

Atualizando Dados

Aplicações Web geralmente atualizam seus dados usando comandos SQL ou, melhor ainda, usando stored procedures parametrizadas. Entretanto, quando se trata de usar dados desconectados, talvez você queira explorar serviços pré-construídos para atualizar todos os registros que precisam ser revisados. Para conseguir isto, o ADO proporciona o mecanismo de atualização batch.

O método UpdateBatch é usado para enviar alterações de Recordset ocorridas no buffer cópia para o servidor para atualização da fonte de dados. Ele utiliza um tipo lock otimista e permite todas as alterações locais pendentes. Ele também envia todas as alterações para a fonte de dados em uma única operação. Um lock otimista ocorre quando a fonte de dados faz o lock dos registros sendo alterados somente quando as alterações são efetuadas. Como resultado, dois usuários podem acessar o mesmo registro ao mesmo tempo e inserir alterações que em breve são sobrescritas umas sobre as outras. É claro, esta abordagem funciona deste que a fonte de dados seja capaz de detectar e rejeitar conflitos de dados. Ela também assume que a fonte de dados como um todo não é extremamente volátil nem está sujeita a alterações freqüentes. Caso contrário, o custo da reconciliação inferida logo sobrepõe as economias de uns poucos locks pessimistas completos. Na verdade, com o método UpdateBatch, é retornado um erro sempre que a alteração falha. Então, você acessa o erro usando a coleção Errors e o objeto Error.

Entender como locks otimistas funcionam no ADO é um elemento chave para entender como o modelo ADO.NET para atualização de dados é significativamente mais poderoso. A partir do código ADO, você chama UpdateBatch e o resto que acontece está além do seu controle. Isto é, atualizações são efetuadas no servidor através do scrolling das linhas que foram alteradas, comparando o valor original com o valor corrente no registro correspondente da fonte de dados. Se tudo coincidir, o comando SQL apropriado (INSERT, UPDATE ou DELETE) é executado na tabela.

O problema aqui é que você não pode controlar o comando SQL que realmente efetua as alterações para você. O código de atualização do lado servidor não é melhor do que o que você escreveu e nem funciona se você almejar um provedor não SQL. No início desta seção, eu afirmei que aplicações Web tipicamente atualizam seus dados através de stored procedures parametrizadas. Entretanto, não é isto que acontece se você usa uma atualização batch.

No ADO.NET, este modelo foi bem expandido. Agora ele segue um esquema mais genérico que permite que você especifique seus próprios comandos para operações básicas como inserção, deleção, atualização e seleção. É fácil ver a intenção de abstrair da fonte de dados e proporcionar o mesmo suporte, independente da natureza da fonte de dados. A atualização batch no ADO.NET requer que você crie um objeto DataSetCommand—o SQLDataSetCommand ou ADODataSetCommand.

Nota No Beta 2, objetos DataSetCommand serão chamados de objetos DataAdapter.

Tendo um objeto DataSetCommand em mãos, você chama seu método Update. O DataSetCommand expõe propriedades como InsertCommand, DeleteCommand, UpdateCommand e SelectCommand. Eles são objetos Command mas você não tem que defini-los a menos que o comportamento padrão não atenda suas expectativas. Isto acontece também no ADO. Durante o Update, se quaisquer das propriedades xxxCommand não foram definidas mas há informação de chave primária, o objeto Command será gerado automaticamente. Note que para que isto funcione, é mandatório ter um conjunto de chave primária para as tabelas de dados envolvidas.

O código seguinte mostra como definir uma chave primária para a tabela EmployeesList de um DataSet:

DataColumn[] keys = new DataColumn[1];

keys[0] = m_oDS.Tables["EmployeesList"].Columns["EmployeeID"];

m_oDS.Tables["EmployeesList"].PrimaryKey = keys;

Uma chave primária é basicamente um array de objetos DataColumn.

Se você quer usar um stored procedure para atualizar uma tabela, ou se você está trabalhando com um provedor de dados proprietário não SQL, você terá que usar estas propriedades de comando freqüentemente.

O Suporte Estendido para XML

No ADO, XML era nada mais do que um mero formato de entrada e saída. Entretanto, no ADO.NET, XML é o formato de dados que proporciona a você uma forma de manipular, reorganizar, compartilhar e transferir seus dados. Qualquer pedaço de dados trazido para um DataSet, independente da origem, pode ser manipulado através de um modelo de programação de dupla face. Você pode acessar pedaços de informação seqüencialmente, linha após linha, assim como seguir um caminho hierárquico não seqüencial orientado pelo modelo de objeto do documento XML.

Um DataSet lê e grava dados e esquema como documentos XML. Tantos dados quantos os esquemas são transportáveis através de HTTP e podem ser usados em qualquer plataforma que entende XML. Os mesmos dados podem ser tratados através de esquemas diferentes (e XSLT descobre seu caminho) em momentos diferentes. Você usa o método ReadXmlSchema para escrever esquemas. Um esquema XML inclui uma descrição das tabelas no conjunto de dados, assim como suas relações e restrições. Você deve fazer isto antes de chamar o método ReadXmlData que popula o DataSet.

O código exemplo seguinte mostra uma página ASP.NET mínima que apresenta uma tabela de dados que pode ser atualizada.

<%@ Import Namespace="System.Data" %>

<%@ Import Namespace="System.IO" %>

<script runat="server" language="C#">

void Page_Load(Object source, EventArgs e)

{

   DataSet data = new DataSet();

   // Loads XML data and schema

   StreamReader sr;

   sr = new StreamReader(Server.MapPath("data.xml"));

   data.ReadXml(sr);

   sr.Close();

   // Add a new record passed through the URL

   if (Request.QueryString.Count >0)

   {

      DataTable dt = data.Tables[0];

      DataRow dr = dt.NewRow();

      dr["FirstName"] = Request.QueryString["First"];

      dr["LastName"] = Request.QueryString["Last"];

      dt.Rows.Add(dr);

      dt.AcceptChanges();

      StreamWriter sw;

      sw = new StreamWriter(Server.MapPath("data.xml"));

      data.WriteXml(sw);

      sw.Close();

   }

      // Refreshes the UI (made of a grid)

   grid.DataSource = data.Tables[0].DefaultView;

   grid.DataBind();

}

</script>

Como demonstrado pela Figura 2, você pode incluir novas linhas na tabela. Entretanto, não há nenhuma tabela SQL Server ou Access por trás disto. É somente um arquivo XML, mas no código que roda contra ele, não há traço de nós XML ou métodos XMLDOM. Você usa a mesma interface intuitiva de tabela de dados para ler e atualizar registros XML. Você poderia fazer a mesma coisa no ADO, mas o modelo aqui é mais profundo e mais amplo e possui um potencial mais forte para a sua exploração.

Figura 2. Exemplo de uma tabela atualizável

Resumo

O sucesso das aplicações Web alteraram o aspecto do sistema distribuído típico. Agora a maior parte dos sistemas de distribuição são sistemas n-tier caracterizados por uma alta, e ainda em crescimento, demanda de escalabilidade e interoperabilidade. Como resultado, desconexão de dados e XML se tornaram melhores práticas e ganharam uma grande aceitação da indústria.

ADO.NET tenta unificar algumas das melhores práticas atuais sob o guarda-chuva do .NET. O modelo de programação geral para o acesso a dados é abrangente e incrivelmente poderoso. Embora o modelo possa não atender todas as suas necessidades individuais, ele é um grande passo em direção ao projeto de um modelo para o futuro. Entretanto, tenha em mente que ADO.NET é uma versão beta e vem com suporte limitado de documentação.

Programadores ADO obterão maior benefício deste beta pois eles já estão familiarizados com muitos aspectos do ADO.NET, incluindo o nível mais alto de abstração—o modelo de inspiração. O código ADO.NET não é compatível com código ADO existente, mas o conjunto de funcionalidades é similar. Para aproveitar totalmente o ADO.NET, você deve colocar algum esforço no entendimento do conceito em si, ao invés de simplesmente descobrir a forma mais fácil de portar seu código. Independente do modelo de programação .NET que você escolha—Windows Forms, Web Forms ou Web Services—ADO.NET estará lá para ajudá-lo nos seus problemas de acesso a dados.

© 2001 Microsoft Corporation. Todos os direitos reservados. Termos de uso.