.net: Обработка исключений при наличии 3 уровня (презентация, бизнес, доступ к данным)? - PullRequest
Новая
       22

.net: Обработка исключений при наличии 3 уровня (презентация, бизнес, доступ к данным)?

0 голосов
/ 13 февраля 2011

предположим, что мы находимся на бизнес-уровне.Существует класс под названием Order.Order отвечает за выполнение процессов для мастер-таблицы на сервере sql (Orders).В этом классе есть метод Insert.Итак, у нас есть

Уровень бизнес-логики: 

Public Class Order
    Public Sub Insert()
        Dim obj As New DAL.Order  'order is its DataAccess class
        Try
             'we first open a Transaction
             obj.Insert()
             Dim objDetail As New OrderDetail 'OrderDetail 
             objDetail.Insert()
             'commit the transaction
        Catch(ex As Exception)
            'we rollback the transaction
        End Try
    End Sub
End Class


Public Class OrderDetail
    Public Sub Insert()
        Dim obj As New DAL.OrderDetail  'OrderDetail is its DataAccess class
        Try
             obj.Insert()
             Dim objDetail As New DAL.OrderDetail 'OrderDetail is its DataAccess class 
             objDetail.Insert()
         Catch(ex As Exception)
             Throw ex
         End Try
    End Sub
End Class

Уровень доступа к данным: 

Public Class OrderDetail
    Public Sub Insert()
        Try
             Using(Command As New SqlCommand)
                 '''code for inserting data into sql server's table
             End Using              
        Catch(ex As Exception)
            Throw ex
        End Try
    End Sub
End Class

Сейчас, мой вопрос: корректна ли обработка выше?Каково ваше предложение?

Ответы [ 3 ]

3 голосов
/ 13 февраля 2011

Вы должны обрабатывать транзакцию на уровне dataAccess как можно ближе к реальной транзакции ... Кроме того, ваши бизнес-объекты не должны иметь над ними операций вставки ...

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

Мой другой комментарий - зачем ловить, если вы просто собираетесь бросить ... избавиться от этой ловушки ...

Лично я бы обернул конкретную конкретную «ошибку сохранения данных» в общую ошибку «не удалось сохранить данные» и вернул бы ее ... конечно, указав исходную ошибку во внутреннем исключении. Таким образом, если вы поменяете местами технологию доступа к данным и тип ошибки изменится, люди, улавливающие ошибку, все равно смогут перехватить ваш конкретный пользовательский тип ошибки и не потерять основную информацию об ошибке.

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

throw;   //and not throw ex;

Это предотвратит потерю трассировки стека

2 голосов
/ 13 февраля 2011

Логика кажется правильной, я бы просто удалил try / catch на уровне доступа к данным, так как вы не делаете ничего полезного в части catch, кроме переброса исключения и очистки трассировки стека , которая могла бы Будь плохим. Что касается бизнес-уровня, то, похоже, все в порядке: именно здесь должны обрабатываться транзакции (запускаться, фиксироваться или откатываться).

0 голосов
/ 13 февраля 2011

Я бы избавился от всех блоков Catch.

Они редко нужны на уровнях business / dal.

Вместо этого просто используйте Try / Наконец или Using, чтобы обеспечить подключение к базе данных.освобождаются и гарантируют откат всех транзакций, которые не были зафиксированы.

И пусть все исключения распространяются на более высокие уровни.

...