Couche d'accès aux données Statique ou basée sur une instance?

Question

Mon application actuelle utilise une couche d'accès aux données basée sur une instance. J'instancie la couche avec la chaîne de connexion. J'appelle alors une méthode qui va faire une sorte de commande. Par exemple, il existe une méthode qui remplira un ensemble de données. Fondamentalement, je passe la procédure stockée et tous les paramètres SQL et récupère un ensemble de données. Est-il préférable d'avoir une classe statique pour gérer mon accès aux données ou une instance basée? J'ai une couche de domaine avec des objets, mais je ne cartographie pas les objets comme le ferait un ORM. Je passe les objets dans des usines qui instancient ensuite la couche de données pour récupérer un ensemble de données. Je fais ensuite correspondre l'ensemble de données à l'objet. Je prévois mettre à jour mon application (et oui passer à C#), mais je n'ai pas le temps de tout changer. Je fais la même chose pour les mises à jour des insertions, et les suppressions. Si ce que je fais est OK pour le moment, faites le moi savoir. Voyez-vous des problèmes avec cette approche? Sinon, que devrais-je faire? Je n'ai pas écrit cette classe. Je l'ai trouvé en ligne et j'ai pensé que c'était ce dont j'avais besoin.

Voici un exemple de la classe de données:

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

D'abord, je pense que l'approche basée sur l'instance est correcte. L'utilisation de classes statiques rendra beaucoup plus difficile le test unitaire de votre DAL et la mise hors service de votre DAL lors de l'essai d'autres classes. Deuxièmement, je pense que vous devriez reconsidérer la construction de votre propre DAL. Vous allez investir beaucoup de temps dans la création, la maintenance et le test de votre couche DAL lorsque vous le pouvez, en utilisant un LINQtoSQL, un nHibernate, un nTier ou même un Entity Framework (qui a déjà fait ses preuves) ORM. code qui profite directement aux besoins de votre entreprise. J'ai fait à la fois, DAL construit à la main et l'ORM, dans mon cas LINQtoSQL, et j'ai constaté que je passe beaucoup moins de temps à tester (et réparer) mon DAL allant la route ORM.

Answer 2

La base d'instance est plus flexible.

Vous pouvez plus facilement changer la technologie sous-jacente (il suffit de fournir une implémentation différente).

Vous pouvez également proxy la couche d'accès aux données. Dans mon cas, j'ai récemment fait cela pour vérifier si quelque chose se trouvait dans la base de données locale, et sinon, en obtenir une copie à partir d'une base de données distante, puis la stocker localement. Cela a été fait de manière totalement transparente pour le reste de l'application.