¿Cuáles son las mejores prácticas para administrar conexiones de bases de datos en .NET?

Question

En cuanto a las mejores prácticas para administrar conexiones de bases de datos en una aplicación .NET, sé que, en general, es malo pasar alrededor de un objeto de conexión.

Sin embargo, tengo algunas curiosidades específicas: (. el niño es privado)

---

1. Tengo dos casos de negocios objetos, de diferentes clases, en una relación padre-hijo ¿Cuál de los siguientes es el mejor?

• Mantener una conexión estática privada abierta y compartida, utilizado por ambos objetos, y dejó abierta hasta que se dispone la matriz.

• Mantenga dos conexiones estáticas privadas abiertas, una para cada objeto, que no sea cerrada hasta que el objeto se elimine.

• No mantener las conexiones estáticas; abra y luego cierre una nueva conexión para cada método que lo requiera. Sin embargo, la mayoría de mis métodos solo ejecutan 1-3 consultas, ¿entonces esto parece ineficiente ...?

---

2. La segunda pregunta es esencialmente el mismo, pero para una sola forma. ¿Qué es mejor aquí?

• Mantener una conexión estática privada abierta y compartido para la vida de la forma.

• No mantener una conexión estática; abrir y cerrar posteriormente una conexión para todos los métodos en la forma que lo requiera (de nuevo, a tan sólo 1-3 consultas por método.)

Answer 1

(era un comentario) ...

La teoría es que no debería estar accediendo a la base de datos de su lógica de negocio - debe estar en una clase de acceso a datos por separado. (Digamos, por ejemplo, en el futuro, necesitas almacenarlos fuera de línea en XML, o usar Oracle en lugar de SQL Server ... ¡no quieres volver a escribir tu lógica de negocios!)

Tus objetos comerciales no deberían tener conexiones de bases de datos asociadas con ellos. La conexión debe abrirse en algún método DAL tipo fábrica, el objeto recuperado/construido, luego se cierra la conexión y se devuelve el objeto.

Los objetos comerciales en sí deberían contener campos y métodos de lógica de negocios, que podrían devolver la llamada a la Capa de acceso a datos, que debería crear una nueva conexión de base de datos para cada método DAL.

Sus miedos de ineficiencia se pueden solucionar mediante el uso de Connection Pooling, lo que significa que si abre y cierra una conexión cientos de veces, es probable que todos utilicen la misma. Pero no debería mantener las conexiones de la base de datos en todo, especialmente no como miembros de una clase.

Espero que ayude!

Answer 2

Mi entendimiento es que las conexiones sólo deben permanecer abiertos todo el tiempo que sea necesario. La mayoría de las veces que he visto en las conexiones Utilización de sentencias, similar a

using (DBConnection db = new DBConnection(connectString)) 
{ 
    //do stuff 
} 

Answer 3

En respuesta a ambas preguntas, si está utilizando algo que tiene la agrupación de conexiones, como ADO.NET, debe codificar sus consultas para mantener la conexión abierta como corto como sea posible. Es decir. open and subsequently close a new connection for every method that requires it.. Cuando cierre la conexión, se devolverá al grupo de conexiones y se reutilizará en una consulta posterior, por lo que no incurrirá en una penalización de rendimiento abriendo y cerrando un grupo de conexiones. La ventaja es que no correrá el riesgo de perder conexiones que olvidó cerrar y, a la larga, tendrá menos conexiones simultáneas abiertas que si mantiene las conexiones abiertas durante largos periodos de tiempo. No importa si la aplicación es un formulario de Windows en lugar de un formulario web: mantenga las conexiones abiertas lo más breve posible.

Answer 4

Este enlace puede ser útil: Best Practices for Using ADO.NET

He aquí un extracto interesante.

Para un mejor rendimiento, mantenga conexiones a la base de datos abierta sólo cuando necesaria. Además, reduzca el número de veces que abre y cierra una conexión para múltiples operaciones.

Siempre he seguido la práctica de abrir conexiones en un bloque en uso, por lo que siempre se llama al método Dispose (y de ahí el método Close) sin preocuparme por ello. Al utilizar este enfoque, nunca me encontré con una situación en la que el mal rendimiento se vinculó a conexiones concurrentes excesivas o a una configuración excesiva o a la destrucción de las operaciones.