VB.net / C# 不要在客户端部分引用 sqlreader 那么在哪里？

Question

假设我有一个包含 5 个文本框的表单，我需要从数据库中提取一些数据，然后使用该数据设置这 5 个文本框。

所以假设我有 3 个基本层：

• default.aspx 页面背后的代码

• 联系 DAL 的 BLL 类

• 和数据访问层 (DAL)

但我听说default.aspx页面不应该知道sqldatareader，实际上你可能不想将sqlclient命名空间添加到default.aspx代码隐藏页面。

所以我曾经做过这样的事情：

protected sub DisplayCustomerData()

Dim s as SqlDataReader
Dim b as BLL

b=new BLL();
s = b.GetCustomerData();

//then take s and simply set each text field
if s.read()
TextBox1.Value = s("MyField1")
end if
end sub

然后 BLL 将简单地调用 DAL 来调用 SQL Server 中的存储过程并执行 CommandObject.ExecuteReader，将结果传递回 BLL，然后 BLL 会将其发送到 default.aspx 的代码隐藏页面。

如果这没有意义，我可以提供完整的源代码。我的问题是，如果 default.aspx 实际上声明并知道 SQL 数据读取器是不好的，那么更好的方法是什么？我应该使用什么数据类型来避免在我的接口代码中使用 sqldatareader？

Answer 1

您已经引入了多个层，但实际上并未分离关注点。通过在您的前端使用 SqlDataReader，它需要太多关于如何检索数据的知识。

通常您会有一个包含检索到的数据的客户Business Object 或Data Transfer Object。您的 DAL 将返回 Customer 类型的对象，而不是对 SqlDataReader 的引用。

protected sub DisplayCustomerData()

    Dim customer as Customer
    Dim b as BLL

    b=new BLL();
    customer = b.GetCustomerData();

    If Not customer is Nothing Then
        TextBox1.Value = customer.MyField
    End If
end sub

更新：

在你的例子中你称之为 BLL，实际上并没有做任何事情。只有数据访问和该数据的呈现。 DAL 本身构建 Customer 对象。

您使用b 的方式，确实是Data Access Object。它与业务逻辑没有任何关系。业务逻辑类似于根据过去的订单确定该客户获得的折扣百分比。

Answer 2

层是关于封装的。多层架构的想法是将关注点分成单独的封装层，例如

数据访问层

封装有关如何执行数据访问的所有信息。不接受或返回任何指示如何执行数据访问的类型（即，它不接受或返回数据读取器、数据集或类似的东西）。它的工作是持久化和检索对象。理想情况下，您应该能够将数据访问层替换为具有相同合同但使用完全不同的持久性机制的数据访问层。

业务逻辑层

执行业务逻辑功能，无论它们可能适用于您的领域。不关心它如何获取数据，也不知道调用者是否是网站、Web 服务、Windows 窗体应用程序等（即它不处理任何 UI 对象）。

表示层

处理内容的呈现，无论是以 API 或网站的形式还是其他形式。如果您以正确的方式编写它，您应该能够拥有多个可以使用您的业务逻辑层的并行表示层。该层不调用数据访问层。

---

请注意，对于您使用的实际层结构没有特别要求，它只是一个相当传统的层结构。例如，我们为缓存管理等内容插入额外的层。