封装数据访问逻辑答案

【问题标题】：Encapsulating Data Access logic封装数据访问逻辑
【发布时间】：2013-11-28 17:49:56
【问题描述】：

我最近购买了 DoFactory 框架，以尝试了解有关设计模式的更多信息。该产品很好，但它只专注于事务性操作，例如用户更新客户记录或插入客户记录。

我有一个有计划任务的应用程序，例如一千个客户是通过网络服务在一夜之间创造出来的。我正在尝试了解解决此问题的最佳方法：

选项 1

public sub shared InsertCustomerBatch(ByVal list as list(as Customer))  
    For Each Customer In Customers
        'Connect to database
        'Insert Customer
    Next
end public

选项 2

Public Sub InsertCustomer(ByVal list as list(as typeCustomer))
    For Each typeCustomer as typeCustomer In list
        Customer.Insert(typeCustomer)
    End For
End Public

这两个选项显然都有效，但我相信选项 2“更好”，因为它遵循设计原则，即 Customer.Insert 封装在 Customer 类中。

但是，在与更高级的开发人员交谈后，他说选择选项 1，但我不明白为什么。选项 1“更好”吗？

【问题讨论】：

即使连接被池化，选项 1 也没有多大意义。选项 2 听起来不错，但您必须每 N 行提交一次。如何指定 N？我想你得试试...可能是 400 好？
@Emmad Kareem，谢谢。每次迭代有一个 sql 语句，所以我不打算使用事务。我认为你在正确的轨道上。您可以发布答案以便我给予信任吗？加 1。
在我看来，主要区别在于，在选项 1 中，您的 DTO 层和数据访问层之间有一个清晰的分离，而在选项 1 中，数据访问对象是无状态的。在选项 2 中，数据和逻辑被融合到一个有状态的类中。它可以工作更多，但我更喜欢选项 1，因为它可以在与选项 2 相同的所有情况下工作，加上一些。在某些情况下，选项 2 将无法轻松发挥作用。
换句话说，如果您遵循选项 1，您可以轻松地创建使它们有状态的包装类，就像在选项 2 中一样。但是，如果您的核心类是按照选项 2 设计的，如果不重写它们，将它们包装在无状态层（如选项 1）中会困难得多。
@Steven Doggart，你能否举个例子，因为我这次实际上不同意你（你已经为我发布了一些我过去同意的好答案）。

标签： vb.net design-patterns

【解决方案1】：

我认为必须证明为什么必须在批处理场景中的每一行打开和关闭连接（选项 1）。一个优点可能是隐式提交。但是，在许多 LOB 应用程序的批处理中通常不需要频繁提交。当然，可能必须做出业务决策来确定数据的敏感性。但是，以合理大小的组（受数据库日志大小限制）提交行是有意义的。

一种方法是将一个大批量大小分成几个小的逻辑批次，并分别提交每个批次。另一种方法是在适当的时候使用大容量复制在数据库中插入行（参见例如：bulk insert data into db。另请注意，默认情况下，除非指定了 CHECK_CONSTRAINTS，否则不会检查表上的约束以进行大容量复制操作。

此外，检查连接超时设置可能会很好，以防它可能对长事务处理产生影响（不确定那个）。但是，我想在您的情况下，默认值应该可以正常工作。

最后，我建议您使用选项 2，如果您的案例需要大量行，可能会根据建议进行一些修改。

【讨论】：

谢谢。为链接 +1。