Actualmente se debate cuáles son los pros y los contras de tener una única arquitectura de conexión sql.CONEXIÓN SQL mejores prácticas
Para elaborar lo que estamos debatiendo es que, en la creación de la aplicación, abra una conexión sql y al cierre de la aplicación o error cerrando la conexión sql. Y no crear otra conexión, sino usar solo esa para hablar con la base de datos.
Nos estamos preguntando qué piensa la comunidad.
Cierre la conexión tan pronto como ya no la necesite durante un tiempo indefinido. Al hacerlo, la conexión vuelve al grupo de conexiones (si la agrupación de conexiones está habilitada) y puede ser (re) utilizada por otra persona.
(Las conexiones son recursos caros, y a veces son limitados).
Si mantiene una conexión durante toda la vida de una aplicación, y tiene varios usuarios para esa aplicación (por lo tanto, varias instancias de la aplicación y conexiones múltiples), y si su servidor de base de datos está limitado a tener solo x número de conexiones simultáneas, entonces usted podría tener un problema ....
Ver también best practices for ado.net
Creo que es una mala idea, por varias razones.
Para expandir el punto 1, debe cerrar las conexiones tan pronto como sea posible, de lo contrario, estará utilizando un recurso finito durante, potencialmente, un período de tiempo ininfinito. Si tenía el servidor Sql configurado para permitir un máximo de 10,001 conexiones simultáneas, entonces solo puede tener 10,001 usuarios ejecutando su aplicación al mismo tiempo. Si abre/cierra conexiones según demanda, su aplicación escalará ya que la probabilidad de que todos los usuarios activos hagan uso de la base de datos simultáneamente es, en realidad, bajo.
Bajo las cubiertas, ADO.NET utiliza la agrupación de conexiones para gestionar las conexiones a la base de datos. Sugeriría dejarlo en el grupo de conexiones para que se encargue de sus necesidades de conexión. Mantener una conexión abierta mientras dure su aplicación es una mala idea.
Siga esta sencilla regla ... Abra la conexión lo más tarde posible y ciérrela lo antes posible.
Uso un sistema de soporte llamado Richmond Systems que usa una conexión durante la vida de la aplicación, y como usuario de computadora portátil, es un dolor real en la parte trasera. Incluso cuando llevo mi laptop abierta, los saltos entre los puntos de acceso inalámbricos son suficientes para dejar caer la conexión DB. El software luego se queja de la conexión DB, entra en un estado de error y no se cierra. Tiene que ser eliminado manualmente del Administrador de tareas.
En resumen, NO MANTENGA ABIERTA LA CONEXIÓN DE LA BASE DE DATOS MÁS DE LO NECESARIO.
Pero por otro lado, soy precavido al abrir y cerrar conexiones con demasiada frecuencia. Esto es mucho más económico con la agrupación de conexiones que sin él, pero incluso con la agrupación, el administrador de la agrupación puede decidir aumentar o reducir el grupo, convirtiéndolo nuevamente en una operación costosa.
Mi regla general es abrir una conexión cuando el usuario inicia alguna acción, hace el trabajo, luego cierra la conexión antes de esperar la siguiente entrada del usuario. Para cualquier botón de "Actualizar" dado, haga clic o lo que sea, generalmente tendré solo una conexión. Pero definitivamente no desea mantener las conexiones abiertas mientras espera la entrada del usuario si puede ayudarlo por todas las razones que otros han mencionado. Literalmente, podría esperar durante días antes de que el usuario presione otra tecla o toque otro botón. ¿Qué sucede si deja su computadora encendida y se va de vacaciones? Atascar un recurso por cantidades de tiempo impredecibles como esa es una mala noticia. En la mayoría de los casos, el tiempo transcurrido esperando la entrada del usuario excederá con creces el tiempo de trabajo real.
Creo que esto también debería interesarle: http://valueinjecter.codeplex.com/wikipage?title=Data%20access%20layer%20%28ORM%29%20with%20the%20Value%20Injecter&referringTitle=Home – Omu