正在阅读：掌握 ASP.NET 之路：自定义实体类简介掌握 ASP.NET 之路：自定义实体类简介

2005-06-23 10:16 出处：作者：Karl Seguin 责任编辑：moningfeng

改进

上文的代码对显示映射的基本概念很有用，但可以在两个关键的方面进行改进。首先，我们需要提取并将代码填充到其自己的函数中，因为代码有可能会被重新使用：

'Visual Basic .NET
Public Function PopulateUser(ByVal dr As IDataRecord) As User
Dim user As New User
user.UserId = Convert.ToInt32(dr("UserId"))
'检查 NULL 的示例
If Not dr("UserName") Is DBNull.Value Then
user.UserName = Convert.ToString(dr("UserName"))
End If
user.Password = Convert.ToString(dr("Password"))
Return user
End Function

//C#
public User PopulateUser(IDataRecord dr) {
User user = new User();
user.UserId = Convert.ToInt32(dr["UserId"]);
//检查 NULL 的示例
if (dr["UserName"] != DBNull.Value){
user.UserName = Convert.ToString(dr["UserName"]);
}
user.Password = Convert.ToString(dr["Password"]);
return user;
}

第二个需要注意的事项是，我们不对映射函数使用 SqlDataReader，而是使用 IDataRecord。这是所有 DataReader 实现的接口。使用 IDataRecord 使我们的映射过程独立于供应商。也就是说，我们可以使用上一个函数从 Access 数据库中映射 User，即使它使用 OleDbDataReader 也可以。如果您将这个特定的方法与 Provider Model Design Pattern（链接 1、链接 2）结合使用，您的代码就可以轻松地用于不同的数据库提供程序。

最后，以上代码说明了封装的强大功能。处理 DataSet 中的 NULL 并非最简单的事，因为每次提取值时都需要检查它是否为 NULL。使用上述填充方法，我们在一个地方就轻松地解决了此问题，使我们的客户无需处理它。

映射到何处？

关于此类数据访问和映射函数的归属问题存在一些争论，即究竟是作为独立类的一部分，还是作为适当自定义实体的一部分。将所有用户相关的任务（获取数据、更新和映射）都作为 User 自定义实体的一部分当然很不错。这在数据库架构与自定义实体很相似时会很有用（比如在本例中）。随着系统复杂性的增加，这两个世界的差异开始显现出来，将数据层和业务层明确分离对简化维护有很大的帮助（我喜欢将其称为数据访问层）。将访问和映射代码放在其自己的层 (DAL) 上有一个副作用，即它为确保数据层与业务层的明确分离提供了一个严格的原则：

“永远不要从 System.Data 返回类或从 DAL 返回子命名空间”