C # clase de base de datos estática?

Question

Tengo una clase de base de datos que contiene los siguientes métodos:

• public bool ExecuteUDIQuery (consulta de cadena) // UDI = Actualizar Eliminar Insertar
• public bool ExecuteSelectQuery (consulta de cadena)
• public bool ExecuteSP (cadena sp, cadena [,] parms)
• public int ExecuteSPReturnValue (string sp, string [,] parms)

Los resultados de los métodos se almacenan en conjuntos de datos privados o tablas de datos. Estos objetos se definen como captadores.

Hay alrededor de 10 clases que usan la clase Base de datos. Cada clase crea un objeto de la clase Base de datos. Ahora estaba pensando en hacer que la clase de base de datos sea estática. ¿Es esta una buena idea? Si es así, ¿por qué? De no, ¿por qué no?

Answer 1

Si entiendo, ¿la clase de base de datos tiene algunas propiedades que almacenan el resultado de la consulta? Si es así, no puede hacerlos estáticos, ya que eso no es seguro para subprocesos. Si el resultado de una consulta se almacena en estas propiedades, ¿qué pasaría si una segunda consulta se ejecutara inmediatamente después de la primera? Se almacenaría en la misma variable estática. Lo mismo ocurre con una aplicación web: el resultado de que otro usuario navegue por el sitio cambiaría los resultados del primer usuario.

EDITAR: para resumir, NO haga que la clase sea estática cuando almacene el resultado de las consultas en variables estáticas, especialmente no cuando la clase se use en un sitio web, ya que el valor de las propiedades se compartirá entre todos los visitantes de su sitio web . Si 20 visitantes hacen una consulta al mismo tiempo, el visitante 1 verá los resultados de la consulta del visitante 20.

Answer 2

En su ejemplo específico, aconsejaría no hacer que la clase sea estática: mantiene el estado en la clase de base de datos, y al hacer que la clase sea estática, ese estado se compartirá entre todas las clases que usan su base de datos. En su configuración actual, cada instancia de la base de datos mantiene su propio estado, por lo que no hay ningún problema con las llamadas de la base de datos que interfieren entre sí.

Si refactoriza la clase Base de datos para devolver los conjuntos de datos al hacer una llamada al método, estaría bien haciéndolo estático: no quedaría información con estado en la clase Base de datos.

Pero como este no es el caso: no, no hagas que la clase sea estática.

Answer 3

Además de los otros comentarios sobre la seguridad de los hilos, también está el tema de la paralelización. En su caso, no podrá abrir varias conexiones a la base de datos al mismo tiempo y no podrá realizar múltiples consultas paralelas, incluso si la seguridad de los resultados no es un problema.

Así que estoy de acuerdo con los demás, no hagas una clase estática.

Hacer la clase estática puede ser conveniente, pero crear nuevas instancias de ella probablemente no será una operación costosa, por lo que probablemente tampoco haya mucho que ganar en cuanto al rendimiento.

Editar:
Vi en un comentario que quieres usar tu clase en un sitio web. En ese caso, REALMENTE no deberías hacer esto. Con una clase de base de datos estática, solo podrá atender de forma segura una solicitud en cualquier momento, y eso no es lo que desea.

Answer 4

Depende de qué tipo de base de datos u ORM esté usando. Pero en mi experiencia, me pareció una buena idea, pero terminó siendo un error. Así es como me fue en LINQ-to-SQL:

Tenía una clase de repositorio que tenía una variable estática en un contexto de datos. Al principio funcionó, pero cuando tuve que hacer muchas más clases de repositorio, terminé recibiendo errores a medida que avanzaba. Resulta que el contexto de datos en LINQ-to-SQL almacena en caché todos los resultados y no hay forma de actualizarlos. Entonces, si agregó una publicación en una tabla en un contexto, no se mostrará en otra que haya almacenado en caché esa tabla. La solución fue eliminar el modificador estático y dejar que el repositorio creara el contexto en el constructor. Dado que las clases del repositorio se construyeron tal como se utilizaron, también lo haría un nuevo contexto de datos nuevo.

Se podría argumentar que las variables estáticas dejan menos huella en la memoria, pero la huella para un contexto de datos es bastante pequeña para empezar y será basura recolectada al final.

Answer 5

Contrariamente a la publicación de respuestas. He creado un marco web con un acceso estático a la base de datos, funciona muy bien y ofrece un gran rendimiento.

Puede consultar el código fuente en http://www.codeplex.com/Cubes

Answer 6

Si solo está ejecutando consultas en la base de datos, entonces sí, hágala estática. Solo tiene que crear una instancia si este objeto necesita mantener algún tipo de estado.

Answer 7

Si tiene un método estático, necesita hacer un seguimiento de las instancias cuando abre y cierra la base de datos.

Entonces, lo que probablemente quiera hacer es tener un Método estático llamado instancia o instancia actual. Y dentro de usted cree una nueva instancia de su clase db devolviéndola en el método estático.

Answer 8

Sus métodos son buenos para el uso estático. Creo que no tiene problemas para convertirlos a métodos estáticos por ahora.

pero más tarde quizás necesite administrar la transacción. dejar la gestión de transacciones a una clase ahorra mucho tiempo, creo. y este escenario se ajusta mejor con una clase no estática.