我应该如何提供对此自定义 DAL 的访问？

Question

我正在为订购系统项目编写自定义 DAL (VB.NET)。我想解释一下它现在是如何编码的，并接受一些替代想法，以使针对 DAL 的编码更容易/更具可读性。 DAL 是 n 层（不是 n 层）应用程序的一部分，其中每一层都位于其自己的程序集/DLL 中。

DAL 由几个具有特定行为的类组成。例如，有一个 Order 类，负责检索和保存订单。大多数类只有两个方法，“Get”和“Save”，每个方法都有多个重载。这些类被标记为 Friend 并且仅对 DAL（位于其自己的程序集中）可见。

在大多数情况下，DAL 返回我所说的“数据对象”。该对象是一个仅包含数据和验证的类，位于 BLL 和 DAL 都可以读取的公共程序集中。

为了提供对 DAL 的公共访问，我当前有一个具有许多共享成员的静态（模块）类。简化版本看起来像这样：

Public Class DAL
    Private Sub New
    End Sub

    Public Shared Function GetOrder(OrderID as String) as OrderData

        Dim OrderGetter as New OrderClass
        Return OrderGetter.GetOrder(OrderID)

    End Function

End Class

Friend Class OrderClass
    Friend Function GetOrder(OrderID as string) as OrderData
    End Function
End Class

BLL 会要求这样的命令：

DAL.GetOrder("123456")

正如你可以想象的，这很快就会变得很麻烦。我主要感兴趣的是构建对 DAL 的访问，以便智能感知非常直观。就目前而言，DAL 类中有太多名称相似的方法/函数。

我的一个想法是将 DAL 分解为嵌套类：

Public Class DAL
    Private Sub New
    End Sub

    Public Class Orders
        Private Sub New
        End Sub

        Public Shared Function Get(OrderID as string) as OrderData
        End Function

    End Class

End Class

所以 BLL 会这样调用：

DAL.Orders.Get("12345")

这会稍微清理一下，但它留下了很多只引用其他类的类，这是我不喜欢的由于某种原因。

在不诉诸从 BLL 到 DAL 传递数据库特定指令（例如 where 子句）的情况下，为 DAL 提供单点访问的最佳或最常见做法是什么？

Answer 1

你所做的确实是一个进步。您已经创建了一系列存储库类，它们的工作就是向您返回实体。您还可以将 Write/Update/Delete 方法放入新的 Orders 对象中，并将这些内容放在一处，这很好。

你最后提出的问题是我们大家都会处理的问题。如果您曾经想知道为什么 LINQ-to-SQL 或 LINQ-to-Entities 很好，这就是原因。它与 IQuerable 接口有关。使用这两种技术中的任何一种，您的 Get 方法都可以返回 IQuerable(Order) （似乎返回所有可能的订单对象），然后您可以对其执行 LINQ；这实际上会将您的业务标准应用到生成的 SQL 查询！乍一看似乎很神奇，但它与 IQuerable 的本质有关。

如果您不使用这样的“db”LINQ 提供程序，那么您必须赢得专业标签并以老式方式进行操作：聪明点。您仍然想利用 LINQ 到对象的优势！哦，是的，你知道。您可以添加一个 GetByCustomer(CustomerID As Int) 来获取客户 ID 并返回 IEnumerable(Order)，这将返回 0 条记录、10 条或 50 条记录，具体取决于记录。 （您的 Customer 对象可能有一个 Orders 属性，它将返回此方法的结果。）但是您不希望为每种可能性不断添加自定义方法。假设您经常希望获得客户的最新订单；您可能想要添加一个GetLatestByCustomer(CustomerID as Int)。

但是，当您仅需要一次客户第二次订单时该怎么办？向 DAL 对象添加一个方法 GetSecondOrderByCustomer() 会很疯狂，对吧？此时，我们的 DAL 对象确实变得混乱了。在这种情况下，您可以针对 GetByCustomer() 方法使用 LINQ：

Dim 2ndOrder As Order = (From O in DAL.Orders.GetByCustomer("123")
                            Order By OrderDate).Skip(1).Take(1)

现在，这非常干净、清晰，并且您不会用我们必须考虑的非常专业的内容来弄乱您的 DAL。要求。但请注意，在幕后您会收到给定客户的每一个订单！这不应该是世界末日；我确定您的 Orders 表有一个按 CustomerID 的索引，对吧？但是，有时您会取回 60 条订单记录，只是为了获取第二条订单记录。

如果在某些时候您有一个非常疯狂的查询需求（获取两个日期之间的所有订单，交付到威斯康星州密尔沃基，通过信用卡支付，通过传真收到），那么您可能必须提供直接 SQL 选项在你的 DAL 中。如果可以的话，你想努力避免这种情况，因为那样你就会失去你的抽象。您可以添加Orders.GetBetweenDates(FirstDate As date, SecondDate As date)。是的 。 。 。但看到危险了吗？后来的一些开发人员可能会调用它来获取几年内的所有订单，然后使用 LINQ 进一步过滤。这很容易导致幕后的表扫描。这些是您必须考虑的事情类型。

你必须谨慎。当你想要抽象（这很好！）时，你必须做出权衡。 LINQ-to-SQL 等的吸引力在于，您可以执行类似于上面示例的 LINQ 查询，并且它只会从数据库获取一条记录！

Answer 2

我建议的一项更改是将 DAL 类基于接口并添加构造函数重载，这将允许您注入依赖项，例如 ORM 组件、连接、命令等......这有很多优点，其中最重要的是您可以单独注入模拟以进行单元测试，并且可以模拟 DAL 本身以进行消费层测试。

这在某种程度上是一个人为的示例，但这是我可以建议的模式的一个非常基本的示例，

Public Interface IDal
    Function GetData(ByVal OrderID As String) As String
End Interface

Public Class Dal : Implements IDal
    Private _connection As IDbConnection

    Public Sub New()
        Me.New(IoC.Resolve(Of IDbConnection))
    End Sub

    Friend Sub New(ByVal Connection As IDbConnection)
        _connection = Connection
    End Sub

    Public Function GetData(ByVal OrderID As String) As String Implements IDal.GetData
        ' Use injected connection and Get the data
    End Function
End Class

请记住，这只是为了说明您可以根据需要修改的模式。请注意构造函数的 Friend 范围。这实际上只意味着由 Frield 类和程序集（例如测试程序集）调用，尽管您当然可以将其公开并让使用层注入它们自己的所有依赖项。

“IoC.Resolve(Of IDbConnection)”位引入了使用您选择的控制反转 (IoC) 容器的概念，尽管实际上并不需要它。只要确保您使用默认的具体实现来更新您的依赖项（如果没有注入）。依赖注入和 IoC 是非常强大的模式，非常适合在 DAL 中使用。希望这有帮助。