Question

假设我们处于业务层。有一个名为Order的类。 Order负责sql server（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

现在，我的问题是：上面的执行处理是否正确？你的建议是什么？

Answer 1

您应该尽可能接近真实交易处理dataAccess层中的交易...此外，您的业务对象不应对其进行“插入”操作......

您应该使用DAL来保留和检索业务对象。您这样做的方式是将数据访问对象注入业务对象。也许这只是我的意见......

我的另一个评论是为什么要抓住，如果你只是要抛出......摆脱那个捕获......

我个人将实际的“数据保存错误”包装在一般的“无法保存数据”错误中并返回...当然指定内部异常中的原始错误。这样，如果您交换实际的数据访问技术和错误类型更改，捕获错误的人仍然可以捕获您的特定自定义错误类型，而不会丢失基础错误详细信息。

如果你想抓住某些东西，然后让原始错误冒出来......请使用

throw;   //and not throw ex;

这可以防止您丢失堆栈跟踪

Answer 2

逻辑似乎是正确的，我只是删除数据访问层中的try / catch，因为除了重新抛出异常和clearing the stack trace之外，你在catch部分没有做任何有用的事情。就业务层而言，它看起来很好：这正是应该处理事务（启动，提交或回滚）的地方。

Answer 3

我会摆脱所有Catch区块。

在商业/ dal层中很少需要它们。

相反，只需使用Try / Finally或Using来确保释放数据库连接，并确保所有未提交的事务都被回滚。

让任何例外传播到更高级别。

.net：具有3层（演示，业务，数据访问）的异常处理？

3 个答案: