Pros y contras del uso del patrón Singleton en DAL

Question

He pedido usar DAL implementado con un patrón único, pero creo que es difícil agrupar las conexiones, usar transacciones ... etc.

Me gustaría saber los pros y los contras y también me gustaría conocer la mejor manera de agrupar las conexiones, ya que puede haber más de 500 usuarios simultáneos para el sitio que estoy desarrollando.

DB Server es Oracle 10g.

DAL usa Enterprise library 3.1

Answer 1

El patrón singleton es excelente para un DAL: lo uso en mi propia aplicación web empresarial (cientos de usuarios y más de 2,000 métodos en 20 clases de singleton). De hecho, ado.net y el servidor sql manejan mejor la agrupación de conexiones. Si desea tener varios tipos de servidor de fondo, eso no es un problema. Incluso con un patrón de singleton, es probable que desee una clase de acceso a datos centralizada que maneje las características específicas de hacer llamadas directas a la base de datos (con parámetros, nombres de texto / procedimiento, credenciales / cadena de conexión, todos pasados).

En mi situación, cada método en un solo corresponde 1: 1 con un procedimiento almacenado en mi base de datos. Esto esencialmente hace un C # '' front-end '' enganche para cada procedimiento almacenado, de modo que puedan llamarse casi como código C # nativo, sintácticamente hablando. Hace que las llamadas al DAL sean muy directas. Tengo múltiples singletons debido a la gran cantidad de SP en cuestión. Cada SP tiene un prefijo, como Development_, o Financial_, u Organization_ o lo que sea. Luego tengo una clase singleton que corresponde a cada uno, como Desarrollo, Financiera u Organización. De modo que sp Organization_ViewData sería en C # un método llamado ViewData en una clase singleton llamada Organization.

Esa es solo una forma de hacerlo, por supuesto, pero he descubierto que funciona muy bien con múltiples desarrolladores y una gran cantidad de código en los últimos seis años. Lo principal es que la consistencia es clave. Si un programador front-end está buscando el nombre de un método en uno de sus corredores singleton, eso debería decirle exactamente a dónde va en el extremo de la base de datos. De esa manera, si hay un problema, o si alguien tiene que buscar a través del código para tratar de entenderlo, hay que rastrear menos.

Answer 2

La mejor práctica para la agrupación de conexiones es no implementarlo usted mismo, sino dejar que el marco ADO.NET se encargue de ello.

Puede configurar las opciones de agrupación de conexiones como parámetros dentro de la cadena de conexión. Luego, cada conexión que se abra con esa cadena se proporcionará desde el conjunto de conexiones implementado y administrado por el marco. Cuando cierre o deseche OracleConnection, la conexión subyacente no se destruirá, sino que volverá al grupo.

Esto se describe aquí:      http://msdn.microsoft.com/en-us/ library / ms254502.aspx

Sobre el uso de Singletons en general: los he usado para ajustar la capa de acceso a datos, y siempre ha funcionado bien.

Tenga en cuenta que las transacciones solo se aplican a conexiones específicas, no a la base de datos en su conjunto. Esto significa que puede tener varios subprocesos en ejecución, y cada subproceso puede leer y escribir en la base de datos a través de transacciones independientes, siempre que cada subproceso use una instancia de OracleConnection separada.

Answer 3

No sé acerca de DAL, pero el patrón de singleton es una excelente manera de hacer que los datos sean globales mientras se mantiene una buena encapsulación.

Answer 4

El uso de un singleton para la fábrica de conexiones de base de datos en el DAL es bastante común. Le permite conectar más fácilmente diferentes implementaciones de fábrica sin cambiar mucho código. A mucha gente no parece gustarle el patrón singleton, pero creo que funciona bien para este tipo de cosas.

Answer 5

Estoy un poco incómodo con el uso de singletons en el caso de un DAL. ¿Qué sucede si quiero usar más de un backend de base de datos? Tal vez quiera usar MsSQL para las facturas pero Active Directory para la autenticación. O tal vez quiero usar MySQL para los mensajes del foro, pero PostgreSQL para geo-clustering (más realista para mí, jeje). Singleton Interfaces puede hacer que la prueba de las capas de la base de datos sea mucho más difícil cuando no puedo pasar una prueba de base de datos simulada a la prueba.

Answer 6

No creo que tenga diferencias de rendimiento si usa un singleton o no, porque aún puede tener múltiples hilos ejecutándose en el mismo método al mismo tiempo. Si cuida de no tener campos internos que se compartirán en todos los subprocesos, todo funcionará bien.

Al final, la clase que administra el grupo de conexiones debe ser segura para subprocesos y terminará haciendo algunos bloqueos que podrían afectar el rendimiento, pero todos son necesarios. (está hecho internamente en el marco y no puede cambiar su comportamiento de todos modos)

Si decides no usar un singleton, asegúrate de que tus instancias de DAL tengan un peso ligero porque esto podría marcar una diferencia, pero generalmente no lo es.

Nota: hablando de los grupos de conexión, lo único importante que debe tener en cuenta es seguir el " abrir tarde, cerrar temprano " modelo. Eso significa, retrase la apertura de la conexión tanto como sea posible y ciérrela CUANTO ANTES después de haber hecho todo lo que necesita con ella.

Después de tener todo el sistema construido con esta regla mágica, puedes jugar con los parámetros de la cadena de conexión para cambiar algunas opciones de grupo (tamaño inicial, tamaño máximo, ...)