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
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.