DESTRUIR SQLDATAADAPTER OU DATATABEL
Trabalhando com 3 camadas, tive de criar os métodos da DAL, BLL e interface UI com estes objetos, pois na consulta ao banco, faço o preenchimento de um DataGridView pelo DataTabla.
Minha dúvida é que tanto na DAL como no BLL, ao criar um New SqlDataAdapter e DataTable para repassar o conteúdo da tabela para o grid, faço isso pelo return dt, mas estes objetos não são destruÃdos ao final de cada método, pois não dá para executar nada após o return..
Sendo assim o que ocorre com estes objetos, vão ficando na memória ? Tem alguma forma de se eliminar mesmo usando o return?
Minha dúvida é que tanto na DAL como no BLL, ao criar um New SqlDataAdapter e DataTable para repassar o conteúdo da tabela para o grid, faço isso pelo return dt, mas estes objetos não são destruÃdos ao final de cada método, pois não dá para executar nada após o return..
Sendo assim o que ocorre com estes objetos, vão ficando na memória ? Tem alguma forma de se eliminar mesmo usando o return?
o C# possui Garbage Colector(GC) que é um recurso que libera recursos do sistema
você pode definir um tratamento try finally para informar ao GC que deve destruir o objeto na proxima limpeza
agora como disse no outro post, só distruimos o que não vamos mais usar. se um datagrid está usando não podemos destruir
você pode definir um tratamento try finally para informar ao GC que deve destruir o objeto na proxima limpeza
Citação:
Code Snippet
DataSet dataSet = null;
DataTable dataTable = null;
try
{
dataSet = new DataSet();
dataTable = new DataTable();
}
catch (Exception)
{
//Tratamento de erro
}
finally
{
if (dataSet != null)
dataSet.Dispose();
if (dataTable != null)
dataTable.Dispose();
}
agora como disse no outro post, só distruimos o que não vamos mais usar. se um datagrid está usando não podemos destruir
[Ô]Usar o return[Ô], não elimina a necessidade de se efetuar o dispose de um objeto. O ideal, seria você além das camadas BLL e DAL, usar uma camada de entidades, criando as classes para cada um de seus objetos e repassar não objetos de banco, como datatables e afins, mas sim, listas ou instâncias dessas entidades.
Agora parece que [Ô]Caiu a Ficha[Ô]. Eu já tinha feito essa camada entidades (Modelo), porém não estava vendo a utilidade na prática, uma vez que em consultas se trás muitos registros, mas o modelo é único. Com o que escreveu então, se entendi bem, eu deveria:
1- Na DAL devo criar uma List<T> do tipo (modelo que fiz para esta entidade)
2- Carregar o DataReader (melhor) ou DataTable, etc... do banco
3- popular o List com os dados do DataReader, etc...
4- Destruir o DataReader
4- Passar o List ao formulário que chamou para popular o controle que quiser no caso Grid.DataSource = List
é isso?
Então só uso os objetos Data quando preciso usá-los posteriormente, que no meu caso é quase nunca.
1- Na DAL devo criar uma List<T> do tipo (modelo que fiz para esta entidade)
2- Carregar o DataReader (melhor) ou DataTable, etc... do banco
3- popular o List com os dados do DataReader, etc...
4- Destruir o DataReader
4- Passar o List ao formulário que chamou para popular o controle que quiser no caso Grid.DataSource = List
é isso?
Então só uso os objetos Data quando preciso usá-los posteriormente, que no meu caso é quase nunca.
é exatamente isso. Banco de dados, na arquitetura multi camadas, deve:
Ser aberto
Ser usado
Ser fechado
E o melhor método para isso são os blocos using:
Ser aberto
Ser usado
Ser fechado
E o melhor método para isso são os blocos using:
List<Clientes> _return = null;
try
{
using (SqlConnection cn = MeuMetodoMirabolanteParaAbrirConexao())
{
using (SqlCommand cmd = New SqlCommand([Ô]select * from minha_tabela[Ô], cn))
{
using (SqlDataReader dr = cmd.ExecuteReader())
{
if (dr.HasRows)
{
_return = new List<Clientes>();
while (dr.Read())
{
Clientes x = new Clientes();
x.Codigo = dr.GetInt32(dr.GetOrdinal([Ô]Codigo[Ô]));
x.Descricao = dr.GetString(dr.GetOrdinal([Ô]Descricao[Ô]));
_return.Add(x);
}
}
}
}
}
}
catch (SqlException ex)
{
//tratar
}
catch (ArgumentException ex)
{
//tratar
}
return _return;
No exemplo acima, seria uma boa prática também, refatorar a parte onde realmente busca os dados para um outro método, que também estaria dentro de um bloco try...catch
Tópico encerrado , respostas não são mais permitidas