Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy .net magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ADO.NET- Artigo easy .net Magazine 11
O artigo descreve o conjunto formado pelo ADO.NET do Framework .NET. Este é composto de namespaces, classes e formas de trabalho que possibilitam um acesso mais simplificado a dados armazenados em diversos tipos de gerenciadores de banco de dados. Além de uma descrição dos principais recursos, são consideradas também as melhores práticas a serem adotadas ao usar estas tecnologias, pensando principalmente em desempenho e em diminuição dos problemas que poderão ocorrer.
Easy .net magazine 11
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy .net magazine 11
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy .net magazine 11
ADO.NET
Como obter melhores resultados no acesso a banco de dados
Boas Práticas com ADO.NET
As tecnologias devem facilitar o trabalho em qualquer área. Ao desenvolver aplicações voltadas para o trabalho com bancos de dados, muitos problemas precisam ser resolvidos com ADO.NET. Entretanto, como qualquer ferramenta, se não houver um conhecimento maior do seu funcionamento, alguns enganos podem comprometer o resultado final. Ao demonstrar a infraestrutura básica desta tecnologia, qual componente usar em cada caso e algumas boas práticas a serem adotadas, será possível fortalecer alguns conceitos que ajudarão ao desenvolver projetos para o mundo real. Um projeto de exemplo foi criado com o propósito de usar algumas das ideias expostas. Este projeto está colocado mais à frente no artigo.
ADO.NET e a camada de acesso aos dados
O ADO.NET é um conjunto de namespaces, classes e interfaces, usado para providenciar um acesso consistente aos diversos tipos de fonte de dados. Outro objetivo de ADO.NET é diminuir significativamente a quantidade de código necessário para interagir com as fontes de dados. Com seus componentes, muitas tarefas podem ser configuradas visualmente, principalmente se o desenvolvedor estiver usando as versões mais recentes do Visual Studio. Uma das principais tarefas do ADO.NET é separar as tarefas de acesso aos dados das de manipulação em partes que podem trabalhar independentes ou em conjunto
Modelos de acesso conectado e desconectado
Existem várias questões a serem consideradas quando se trabalha com ADO.NET. A primeira sem dúvida é o modelo de acesso aos dados que pode ser feito de duas formas: conectado e desconectado. Ao trabalhar conectado o desenvolvedor precisa estabelecer um canal com a fonte de dados por onde será feita a leitura ou escrita com os dados. Isto só pode ser feito enquanto o canal estiver aberto.
Operações tipicamente conectadas são:
1. Execução de inserção, alteração e exclusão dos dados no banco;
2. Leitura unidirecional dos dados. Este tipo de leitura não permite uma navegação bidirecional pelos registros. Um uso típico é a leitura dos dados para geração de relatórios ou exibição em páginas estáticas.
As classes que são indicadas para este trabalho são implementações das Interfaces IDbCommand, IDbDataReader e IDbConnection. Mais à frente será considerada a questão dos DataProviders, que fazem implementações customizadas destas classes.
O modelo de acesso permite que se carreguem os dados para serem usados pela aplicação sem ser necessário manter uma conexão permanente com a fonte de dados. Assim, podem-se editar os dados, navegar pelos registros sendo que só quando for necessário, seja estabelecida uma conexão com o banco de dados para o eventual envio das alterações feitas localmente. O trabalho é feito basicamente com as classes DataTable e DataSet e com as implementações das interfaces de IDataAdapter e IDataParameter.
Nota: Estas interfaces definem o modelo de acesso que o Framework .NET provê. Cada banco de dados deve implementar as classes mais apropriadas para o acesso sendo que os padrões do ADO.NET são: System.Data.OleDb, Sytem.Data.Odbc, System.Data.SqlClient e System.Data.OracleClient (que deve ser baixado).
Data Providers
Os Data Providers proporcionam uma camada mínima entre as fontes de dados e o código por serem leves e causarem pouco impacto. Estes componentes servem de pontes entre a fonte de dados e a aplicação. Uma preocupação inicial é usar o data provider correto para o tipo de banco de dados que se está usando. Observe na Figura 1 onde é feito um comparativo do acesso ao SQL Server usando o data provider nativo e outros. Note que usando o SqlClient, o número de camadas até o banco é mínimo. Os principais data providers do framework são os da Tabela 1.
DataSet e TableAdapter
Os DataSets são os componentes usados para armazenar os dados. Representam os dados do banco de dados armazenados na memória e estruturados em tabelas. Podem ser definidos como um conjunto de objetos DataTable, também usados em conjunto com TableAdapters – estes últimos, derivados dos DataAdapters. Com estes componentes no projeto o desenvolvedor define as consultas ao banco de dados para recuperar os dados em DataTables, definindo as consultas com TableAdapters vinculados com estas. É indicado para o trabalho desconectado. Ao definir os TableAdapters vinculados com o DataTable, cria-se uma classe fortemente tipada com as colunas do banco de dados mapeadas para o projeto e com a possibilidade de definir várias consultas, sendo que cada uma gera um método Fill para preenchimento dos dados.
A classe DataSet é definida no namespace System.Data. Pode ser definida via código ou visualmente quando se usa o Visual Studio. Um dos pontos principais a se observar é que ao usar o designer, muito código é gerado para implementar as funcionalidades básicas, como a geração automática das instruções SQL para inserção, atualização e exclusão dos dados. Se muitas tabelas forem definidas sem critério e o DataSet ficar muito extenso, a sua manipulação no projeto do Visual Studio se torna muito lenta. Já citei exemplos em artigos anteriores onde a geração de uma tabela num DataSet gerou um código de mais de três mil linhas. Por isto, é importante tomar cuidado. Se for usar o DataSet, procure separar por partes do sistema. Você pode criar um DataSet para cada módulo como, por exemplo: Estoque, Finanças etc.
"
Este é um post disponível para assinantes MVP
Como obter melhores resultados no acesso a banco de dados
Boas Práticas com ADO.NET
As tecnologias devem facilitar o trabalho em qualquer área. Ao desenvolver aplicações voltadas para o trabalho com bancos de dados, muitos problemas precisam ser resolvidos com ADO.NET. Entretanto, como qualquer ferramenta, se não houver um conhecimento maior do seu funcionamento, alguns enganos podem comprometer o resultado final. Ao demonstrar a infraestrutura básica desta tecnologia, qual componente usar em cada caso e algumas boas práticas a serem adotadas, será possível fortalecer alguns conceitos que ajudarão ao desenvolver projetos para o mundo real. Um projeto de exemplo foi criado com o propósito de usar algumas das ideias expostas. Este projeto está colocado mais à frente no artigo.
ADO.NET e a camada de acesso aos dados
O ADO.NET é um conjunto de namespaces, classes e interfaces, usado para providenciar um acesso consistente aos diversos tipos de fonte de dados. Outro objetivo de ADO.NET é diminuir significativamente a quantidade de código necessário para interagir com as fontes de dados. Com seus componentes, muitas tarefas podem ser configuradas visualmente, principalmente se o desenvolvedor estiver usando as versões mais recentes do Visual Studio. Uma das principais tarefas do ADO.NET é separar as tarefas de acesso aos dados das de manipulação em partes que podem trabalhar independentes ou em conjunto
Modelos de acesso conectado e desconectado
Existem várias questões a serem consideradas quando se trabalha com ADO.NET. A primeira sem dúvida é o modelo de acesso aos dados que pode ser feito de duas formas: conectado e desconectado. Ao trabalhar conectado o desenvolvedor precisa estabelecer um canal com a fonte de dados por onde será feita a leitura ou escrita com os dados. Isto só pode ser feito enquanto o canal estiver aberto.
Operações tipicamente conectadas são:
1. Execução de inserção, alteração e exclusão dos dados no banco;
2. Leitura unidirecional dos dados. Este tipo de leitura não permite uma navegação bidirecional pelos registros. Um uso típico é a leitura dos dados para geração de relatórios ou exibição em páginas estáticas.
As classes que são indicadas para este trabalho são implementações das Interfaces IDbCommand, IDbDataReader e IDbConnection. Mais à frente será considerada a questão dos DataProviders, que fazem implementações customizadas destas classes.
O modelo de acesso permite que se carreguem os dados para serem usados pela aplicação sem ser necessário manter uma conexão permanente com a fonte de dados. Assim, podem-se editar os dados, navegar pelos registros sendo que só quando for necessário, seja estabelecida uma conexão com o banco de dados para o eventual envio das alterações feitas localmente. O trabalho é feito basicamente com as classes DataTable e DataSet e com as implementações das interfaces de IDataAdapter e IDataParameter.
Nota: Estas interfaces definem o modelo de acesso que o Framework .NET provê. Cada banco de dados deve implementar as classes mais apropriadas para o acesso sendo que os padrões do ADO.NET são: System.Data.OleDb, Sytem.Data.Odbc, System.Data.SqlClient e System.Data.OracleClient (que deve ser baixado).
Data Providers
Os Data Providers proporcionam uma camada mínima entre as fontes de dados e o código por serem leves e causarem pouco impacto. Estes componentes servem de pontes entre a fonte de dados e a aplicação. Uma preocupação inicial é usar o data provider correto para o tipo de banco de dados que se está usando. Observe na Figura 1 onde é feito um comparativo do acesso ao SQL Server usando o data provider nativo e outros. Note que usando o SqlClient, o número de camadas até o banco é mínimo. Os principais data providers do framework são os da Tabela 1.
DataSet e TableAdapter
Os DataSets são os componentes usados para armazenar os dados. Representam os dados do banco de dados armazenados na memória e estruturados em tabelas. Podem ser definidos como um conjunto de objetos DataTable, também usados em conjunto com TableAdapters – estes últimos, derivados dos DataAdapters. Com estes componentes no projeto o desenvolvedor define as consultas ao banco de dados para recuperar os dados em DataTables, definindo as consultas com TableAdapters vinculados com estas. É indicado para o trabalho desconectado. Ao definir os TableAdapters vinculados com o DataTable, cria-se uma classe fortemente tipada com as colunas do banco de dados mapeadas para o projeto e com a possibilidade de definir várias consultas, sendo que cada uma gera um método Fill para preenchimento dos dados.
A classe DataSet é definida no namespace System.Data. Pode ser definida via código ou visualmente quando se usa o Visual Studio. Um dos pontos principais a se observar é que ao usar o designer, muito código é gerado para implementar as funcionalidades básicas, como a geração automática das instruções SQL para inserção, atualização e exclusão dos dados. Se muitas tabelas forem definidas sem critério e o DataSet ficar muito extenso, a sua manipulação no projeto do Visual Studio se torna muito lenta. Já citei exemplos em artigos anteriores onde a geração de uma tabela num DataSet gerou um código de mais de três mil linhas. Por isto, é importante tomar cuidado. Se for usar o DataSet, procure separar por partes do sistema. Você pode criar um DataSet para cada módulo como, por exemplo: Estoque, Finanças etc.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy .net magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
O que você achou deste post?
Cursos relacionados
Publicidade
