Data Access Layer Static or Instance based?

Question

My current application is using an instance based data access layer. I instantiate the layer with the connection string. I then call a method that will do some sort of command. For example there is a method that will fill a dataset. Basically, I pass the stored procedure and any SQL parameters and get back a dataset. Is it better to have a static class to handle my data access or an instance based? I do have a Domain layer with objects, but I am not mapping the objects like an ORM would. I am passing the objects into factories that then instantiates the data layer to pull back a dataset. I then map the dataset to the object. I plan on updating my app (and yes moving to C#), but I do not have the time to change the entire thing. I do the same thing for inserts updates, and Deletes. If what I am doing is OK for now, let me know. Do you see any issues with this approach? Otherwise, what should I be doing? I did not write this class. I found it on-line and thought this is what I needed.

Here is an example of the data class:

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

First, I think that the instance-based approach is correct. Using static classes will make it much more difficult to unit test your DAL and to mock your DAL out when unit testing other classes. Second, I think you ought to reconsider building your own DAL. You'll invest a lot of time in creating, maintaining, and testing your DAL when you could, by using an existing (well-tested) ORM -- like LINQtoSQL, nHibernate, nTier, or even Entity Framework -- spend more time on code that directly benefits your business needs. I've done both, hand-built DAL and the ORM, in my case LINQtoSQL, and I've found that I spend much less time testing (and fixing) my DAL going the ORM route.

Answer 2

The instance base one is more flexible.

You can more easily change out the underlying technology (just provide a different implementation).

You can also proxy the data access layer. In my case I recently did this to check to see if something was in the local database, and if not get a copy of it from a remote database and then store it locally. This was done entirely transparently to the rest of the application.