¿Capa de acceso a datos estática o basada en instancia?

Question

Mi aplicación actual está utilizando una capa de acceso a datos basada en instancia. Instanciamos la capa con la cadena de conexión. Luego llamo a un método que hará algún tipo de comando. Por ejemplo, hay un método que completará un conjunto de datos. Básicamente, paso el procedimiento almacenado y los parámetros SQL y recupero un conjunto de datos. ¿Es mejor tener una clase estática para manejar mi acceso a datos o una instancia basada? Tengo una capa de Dominio con objetos, pero no estoy mapeando los objetos como lo haría un ORM. Paso los objetos a fábricas que luego instancian la capa de datos para extraer un conjunto de datos. Luego mapeo el conjunto de datos al objeto. Planeo actualizar mi aplicación (y sí pasar a C#), pero no tengo tiempo para cambiar todo. Hago lo mismo para las actualizaciones de inserciones y elimina. Si lo que estoy haciendo está bien por ahora, házmelo saber. ¿Ves algún problema con este enfoque? De lo contrario, ¿qué debería estar haciendo? No escribí esta clase. Lo encontré en línea y pensé que esto es lo que necesitaba.

Aquí es un ejemplo de la clase de datos:

Public Sub New(ByVal connectionString As String) 
     _connectionString = connectionString 
    End Sub 

Public Function FillDataset(ByVal cmd As String, ByVal cmdType As CommandType, Optional ByVal parameters() As SqlParameter = Nothing) As DataSet 
     Dim connection As SqlConnection = Nothing 
     Dim command As SqlCommand = Nothing 
     Dim sqlda As SqlDataAdapter = Nothing 
     Dim res As New DataSet 
     Try 
      connection = New SqlConnection(_connectionString) 
      command = New SqlCommand(cmd, connection) 
      command.CommandType = cmdType 
      AssignParameters(command, parameters) 
      sqlda = New SqlDataAdapter(command) 
      sqlda.Fill(res) 
     Catch ex As Exception 
      'CreateDataEntry(ex, WriteType.ToFile, cmd) 
     Finally 
      If Not (connection Is Nothing) Then connection.Dispose() 
      If Not (command Is Nothing) Then command.Dispose() 
      If Not (sqlda Is Nothing) Then sqlda.Dispose() 
     End Try 
     Return res 
    End Function 

     Public Function ExecuteNonQuery(ByVal spname As String, ByVal ParamArray parameterValues() As Object) As Object 
     Dim connection As SqlConnection = Nothing 
        Dim command As SqlCommand = Nothing 
     Dim res As Object = Nothing 
     Try 
      connection = New SqlConnection(_connectionString) 
      command = New SqlCommand(spname, connection) 
      command.CommandType = CommandType.StoredProcedure 
      command.Parameters.AddRange(parameterValues) 
      connection.Open() 
      command.ExecuteNonQuery() 
      res = command.Parameters(command.Parameters.Count - 1).Value 
     Catch ex As Exception 
      CreateDataEntry(ex, WriteType.ToFile, spname) 
      If Not (transaction Is Nothing) Then 
       transaction.Rollback() 
      End If     
     Finally 
      If Not (connection Is Nothing) AndAlso (connection.State = ConnectionState.Open) Then connection.Close() 
      If Not (command Is Nothing) Then command.Dispose()     
     End Try 
     Return res 
    End Function 

Answer 1

En primer lugar, creo que el enfoque basado en instancia es correcta. El uso de clases estáticas hará que sea mucho más difícil probar la unidad de su DAL y simular su DAL cuando la unidad pruebe otras clases. Segundo, creo que deberías reconsiderar la construcción de tu propio DAL. Invertirá mucho tiempo creando, manteniendo y probando su DAL cuando pueda, utilizando un ORM existente (bien probado), como LINQtoSQL, nHibernate, nTier o incluso Entity Framework: dedique más tiempo a código que beneficia directamente las necesidades de su negocio. He hecho ambos, DAL construido a mano y el ORM, en mi caso LINQtoSQL, y he descubierto que paso mucho menos tiempo probando (y solucionando) mi DAL en la ruta ORM.

Answer 2

La base de la instancia uno es más flexible.

Puede cambiar más fácilmente la tecnología subyacente (solo proporcione una implementación diferente).

También puede realizar un proxy de la capa de acceso a datos. En mi caso, recientemente hice esto para verificar si había algo en la base de datos local y, si no, obtener una copia de una base de datos remota y luego almacenarla localmente. Esto se hizo de manera totalmente transparente para el resto de la aplicación.