ASP.NET/ADO.NET: Manipulação muitas conexões de banco de dados dentro de um objeto .NET?

Question

Temos um objeto .NET que faz um monte de leitura / escrita com o banco de dados. Durante todo o ciclo de vida deste objeto (ou a página asp que usa-lo), ele pode bater o banco de dados com uma qualquer consulta / atualização de 1 a 10 vezes.

Em vez de abrir e fechar uma conexão de banco de dados cada vez que o objeto precisa bater o banco de dados, ele simplesmente abre uma conexão com o banco de dados durante a instanciação e depois fecha a conexão durante rescisão do objeto. É que uma má prática?

A suposição era que desde que o objeto atinge o banco de dados cada vez que é instanciado (e geralmente várias vezes), seria melhor apenas para abrir uma conexão no início da vida do objeto e, em seguida, fechá-lo no final.

A outra alternativa é abrir e fechar a conexão de banco de dados antes e depois de cada consulta / operação.

Qual é a melhor prática aqui, a fim de maximizar o desempenho?

**** atualização **** Obrigado pelas dicas caras. Alguém pode falar mais com o método de abrir / fechar uma conexão dentro eventos instanciação / terminação de um objeto e as repercussões de fazê-lo?

Answer 1

Abra uma estreita ligação, conforme necessário. ADO.NET foi construído em pool de conexão que funciona. Você não vai notar quaisquer problemas de desempenho, a menos que você está fazendo isso em um loop com milhares de / fecha abertos.

editar Consulte devo persistir um sqlconnection na minha camada de acesso a dados? para obter mais informação sobre as armadilhas da persistência de conexão.

Answer 2

abrir e fechar cada vez ... Abrir imediatamente (o mais próximo possível) antes da linha de código que executa reais a operação de banco de dados, e perto o mais rapidamente possível imediatamente depois. Quando você fizer isso, desta forma, ADO.net na verdade não fechar a conexão, ele apenas libera-lo de volta para o Connection ADO.net Pool, onde se senta e espera que a próxima solicitação para uma conexão com a mesma cadeia conenction. Você não está incorrendo na ovberhead de realmente recriar a ligação de cada vez ...

A única questão é se você está de forma assíncrona fazendo tantas tentativas de conexão que você exceder o número máximo de conexões na piscina .... e há soluções para esta questão, bem como, usando a classe System.Threading.ThreadPool. ..

Answer 3

Para aumentar a confiança no argumento pool de conexão - segurando a abrir conexão por mais tempo do que o necessário pode realmente diminuição desempenho geral, como o pool de conexão não pode compartilhar a conexão com outros componentes que necessitam de um DB conexão.

Então, sim, abrir e fechar a conexão, conforme necessário. Embora, seria ainda mais rápido se você pudesse lote suas consultas em uma única chamada exec.

Answer 4

Mesmo quando ado.net na verdade não fechar a ligação, quando você faz: Conn.Close () executa "sp_reset_connection" no servidor, mesmo quando sp_reset_connection é um procedimento de armazenamento leve, gerar algum tráfego de rede. Assim, por exemplo, eu não recomendaria fechando e abrindo a conexão dentro de um loop.