Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Revista MSDN Magazine Edição 11 - Migrando do ADO para o ADO.NET, Parte 2
Artigo Originalmente Publicado na MSDN Magazine Edição 11
Clique aqui para ler todos os artigos desta edição
Migrando do ADO para o ADO.NET, Parte 2
por John Papa
À medida que progredir no uso do ADO.NET, você precisará saber como abordar no ADO.NET situações com as quais costumava lidar no ADO. Assim como as soluções n-tiered desenvolvidas por meio do Visual Basic®, C++ e ASP geralmente dependem do ADO para suas necessidades de acesso aos dados, os Windows® Forms, os Web Forms e os Web services dependem do ADO.NET. Na coluna do mês passado (edição 10 da MSDN Magazine Brasil), analisamos como tratar diversos cenários de acesso a dados usando o ADO.NET a partir da perspectiva de desenvolvimento com o ADO tradicional. Alguns desses tópicos incluem a persistência de rowsets para XML, lidar com cursores firehose forward-only e as várias maneiras de executar objetos Command.
Na coluna deste mês, continuarei a analisar as situações de desenvolvimento por meio do ADO.NET e descreverei como tratá-las com as técnicas ADO tradicionais. Começarei analisando as situações em que os cursores forward-only, estáticos, keyset e dinâmicos do ADO clássico foram comumente usados. Analisarei também como as questões de concorrência são tratadas e como os rowsets desconectados evoluíram do ADO para ADO.NET. Em seguida, demonstrarei como usar o código que trata atualizações de batch no ADO tradicional e convertê-lo para que funcione com o ADO.NET, usando o DataAdapter e seus quatro objetos Command.
Divergência de Recordset
A maioria dos recursos de Recordset do ADO é dividida em três objetos-chave no ADO.NET: o DataReader, o DataSet e o DataAdapter (consulte a Figura 1).
Figura 1 O Recordset ADO
O objeto ADO.NET DataReader é projetado para ser um cursor no lado do servidor (server-side), forward-only e de somente-leitura. O objeto ADO.NET DataSet consiste em uma ferramenta de armazenamento desconectada para rowsets. Ele armazena registros sem precisar manter uma conexão com uma fonte de dados e, na verdade, ele não se importa com a fonte de dados da qual os rowsets são derivados. O DataSet é um objeto binário quando armazenado na memória, mas ele também pode ser facilmente serializado para/de XML. Ele é semelhante ao objeto ADO Recordset, com seu CursorType definido como adOpenStatic, e CursorLocation definido como adUseClient, quando ele tiver sido desconectado de seu objeto Connection associado (por meio da propriedade ActiveConnection do Recordset). O objeto ADO.NET DataAdapter consiste em uma ponte entre a conexão e os objetos DataSet. Ele pode carregar um DataSet a partir de uma fonte de dados por meio de uma conexão e pode atualizar a fonte de dados com as alterações armazenadas em um DataSet. O comportamento do ADO Recordset depende de suas configurações de propriedade (incluindo as propriedades CursorType e CursorLocation). No ADO.NET, são criados objetos separados para lidar com essas situações específicas, em vez de se utilizar um objeto para atender a todos os cenários.
Cursores Firehose
O ADO tradicional expõe quatro tipos diferentes de cursores que alteram a forma como o objeto ADO Recordset funciona. No ADO Recordset, o objeto se comporta de forma muito diferente, dependendo de como sua propriedade CursorType é definida. Por exemplo, definindo-se CursorType como adOpenForwardOnly, o Recordset permanece conectado à sua fonte de dados e precisa ser percorrido em uma direção contínua (forward-only). No entanto, quando você define a propriedade CursorType como adOpenDynamic, o Recordset pode ser percorrido para frente ou para trás, ou você pode até fazer com que o cursor salte para uma linha específica. Por intermédio de suas propriedades CursorType e CursorLocation, o objeto ADO Recordset utiliza a abordagem de reunir várias soluções em um único objeto. O ADO.NET usa um comportamento diferente, já que possui diferentes objetos e métodos para lidar com situações específicas.
No ADO clássico, os cursores forward-only e somente-leitura são implementados definindo-se CursorType como adOpenForwardOnly e CursorLocation como adUseServer (que são também as definições padrão). Isso faz com que o objeto Recordset assuma a forma de um cursor forward-only no lado do servidor. O método MoveNext reposiciona o Recordset na próxima linha e o método MovePrevious não é aceito em nenhuma circunstância. No entanto, você poderá chamar o método MoveFirst em um Recordset. Entretanto, esse método é um tanto enganoso, já que ele não se reposiciona no início do rowset atual. Em vez disso, ele chama a instrução SQL original e preenche novamente o Recordset a partir do zero, movendo-se assim para o próximo registro.
Você pode constatar isso facilmente abrindo a ferramenta SQL Profiler e observando a execução do SQL a cada vez que o método MoveFirst é executado em um ADO Recordset tradicional com um CursorType definido como adOpenForwardOnly. Esse tipo de cursor é geralmente usado em aplicações onde é necessário percorrer milhares de linhas (ou mais) individualmente (uma por vez) ou quando é necessário um rowset menor mas que só precise ser percorrido uma vez, possivelmente para ser carregado em uma lista de seleção:
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
John Papa
é um fanático em basebol que passa a maior parte de suas noites de verão torcendo pelos Yankees com suas duas filhinhas, sua esposa e um cão fiel, Kadi. É autor de vários livros sobre ADO, XML, e SQL Server e geralmente pode ser encontrado dando palestras em conferências do setor, como o VSLive.
