Уровень доступа к данным Статический или на основе экземпляров? - PullRequest
Новая
       33

Уровень доступа к данным Статический или на основе экземпляров?

6 голосов
/ 14 марта 2009

Мое текущее приложение использует слой доступа к данным на основе экземпляра. Я создаю экземпляр слоя со строкой соединения. Затем я вызываю метод, который выполняет какую-то команду. Например, есть метод, который заполнит набор данных. По сути, я передаю хранимую процедуру и любые параметры SQL и получаю обратно набор данных. Лучше иметь статический класс для обработки моего доступа к данным или на основе экземпляра? У меня есть слой Domain с объектами, но я не отображаю объекты, как ORM. Я передаю объекты на фабрики, которые затем создают экземпляр уровня данных для извлечения набора данных. Затем я сопоставляю набор данных с объектом. Я планирую обновить свое приложение (и да, перейти на C #), но у меня нет времени, чтобы изменить все это. Я делаю то же самое для вставок обновлений и удалений. Если то, что я делаю, пока нормально, дайте мне знать. Видите ли вы какие-либо проблемы с этим подходом? В противном случае, что я должен делать? Я не писал этот класс. Я нашел его в Интернете и подумал, что это то, что мне нужно.

Вот пример класса данных: 

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

Ответы [ 2 ]

7 голосов
/ 14 марта 2009

Во-первых, я думаю, что подход на основе экземпляров является правильным. Использование статических классов значительно усложнит юнит-тестирование вашего DAL и макетирование вашего DAL при юнит-тестировании других классов. Во-вторых, я думаю, вам следует пересмотреть вопрос о создании собственного DAL. Вы будете тратить много времени на создание, обслуживание и тестирование своего DAL, когда можете, используя существующую (хорошо протестированную) ORM - такую ​​как LINQtoSQL, nHibernate, nTier или даже Entity Framework - тратить больше времени на Кодекс, который непосредственно приносит пользу вашим бизнес-потребностям. Я сделал как DAL, так и ORM, в моем случае LINQtoSQL, и обнаружил, что трачу гораздо меньше времени на тестирование (и исправление) моего DAL по маршруту ORM.

1 голос
/ 15 марта 2009

Базовый экземпляр более гибкий.

Вы можете легко изменить базовую технологию (просто предоставьте другую реализацию).

Вы также можете прокси слой доступа к данным. В моем случае я недавно сделал это, чтобы проверить, есть ли что-то в локальной базе данных, а если нет, получить копию из удаленной базы данных и затем сохранить ее локально. Это было сделано полностью прозрачно для остальной части приложения.

...