过度使用 DataTable 是不是很糟糕？

Question

我最近被要求协助另一个团队构建一个 ASP .NET 网站。他们已经编写了大量代码——我被特别要求为该网站构建几个单独的页面。

在探索网站其余部分的代码时，正在构建的 DataTables 的数量让我大吃一惊。作为该领域的一个相对较新的人，我从来没有开发过像这个站点那样使用数据库的应用程序，所以我不确定这有多普遍。似乎每当从我们的数据库中查询数据时，结果都存储在 DataTable 中。然后这个 DataTable 通常会自行传递，或者传递给构造函数。使用 DataTable 初始化的类总是将 DataTable 分配给私有/受保护的字段，但是这些类中只有少数实现了 IDisposable。事实上，到目前为止，在我浏览的数千行代码中，我还没有看到在 DataTable 上调用的 Dispose 方法。

如果有的话，这似乎不是一个好的 OOP。这是我应该担心的事情吗？还是我只是比我应该更关注细节？假设您是比我最有经验的开发人员，如果刚刚被指派帮助您开发网站的人就这个“问题”与您联系，您会有什么感觉或反应？

Answer 1

在非常高的层次上，软件系统架构可以被描述为使用几种“企业级模式”之一，Transaction script、Table Model、Domain Model 或 Service Layer。如果您正在审查的系统使用 Table Model 模式，那么您会期望看到比在使用 Domain Model 设计的系统中更多地使用 DataTables 和 DataSets em> 或其他模式之一。

然而，随着过去几年软件系统设计方法的发展，人们普遍认为复杂系统不能很好地使用事务脚本或表模型架构。这通常是因为在使用这些模式设计的系统中，功能通常更加交织和相互关联，并且随着复杂性的增长，功能或模块相互依赖的数量呈指数增长，并且变得难以快速管理。因此，根据您的特定系统的复杂程度，是的，如果在系统的多个层中使用 DataSet 和/或 DataTables，您应该怀疑。这可能表明系统设计者曾经/正在使用表模型（有意或无意地）他/她应该使用域模型或服务层架构。

Answer 2

数据表可用于善恶。

可接受的使用

我认为以下是可接受的数据表或数据行用法：

public class User
{
    private DataRow Row { get; set; };
    public User(DataRow row) { this.Row = row; }

    public string UserName { get { return (string)Row["Username"]; } }
    public int UserID { get { return (int)Row["UserID"]; } }
    public bool IsAdmin { get { return (bool)Row["IsAdmin"]; } }
    // ...
}

上面的类是ok，因为它将DataRow 映射到一个类型安全的类。现在您可以使用真正的数据类型和智能感知来帮助您，而不是使用字符串和无类型的数据行。此外，如果您的数据库架构发生更改，您可以修改对象中的列名，而不是在任何使用它的地方修改列名。最后，您可以将难看的列名（例如“dtaccount_created”）映射到名为“AccountCreated”的属性。

当然，编写这个包装类确实没有什么好理由，因为 Visual Studio 会自动为您生成typed datasets。或者，作为替代方案，像 NHibernate 这样好的 ORM 允许您定义与上述类似的类。

您应该使用普通的旧 ADO.NET、类型化数据集还是完整的 ORM，取决于您的应用程序的要求和复杂性。如果没有实际看到一些示例代码，很难说您的团队是否在做正确的事情。

此外，我偶尔会发现将列表和网格与数据表进行数据绑定很有用，因为对底层数据行的更改会自动导致 GUI 刷新。如果您创建自己的类型安全包装器，则需要手动实现 IPropertyChanging 和 IPropertyChanged 接口。

不可接受的使用

不幸的是，我看到程序员将数据表用于临时容器、类的替代品等。如果您看到您的团队这样做，请向他们扔石头。这种编程风格在静态类型语言中是行不通的，它会让开发成为一场噩梦。

数据表的主要问题：它们没有类型，所以如果不给它们一个字符串并将它们包含的任何神秘对象转换为正确的类型，你就无法对它们做任何有用的事情。此外，重构列名几乎不可能自动化，因为它们是基于字符串的，因此您不能依赖智能感知来帮助您编写正确的代码，也无法在编译时捕获错误。

我说相信你的直觉：如果你认为设计是脆弱的，它可能就是。

Answer 3

使用 DataTable 可能是一种懒惰/低效的数据存储方式。这样做有很大的开销。您的担心是对的，尽管开发人员可能在听到他们设计此应用程序的糟糕程度时遇到了真正的问题。管理层会在你创造更优质产品的目标中支持你吗？他们可以接受相关的开发延迟吗？

Answer 4

这绝对是您应该担心的事情 - 请参阅相关帖子 on the importance of Disposing DataTables。

DataTables是可终结的：如果您不主动处置它们，它们会比 Gen0 集合停留更长的时间并消耗内存。

要测量应用程序的损坏程度，您可以使用 WinDbg 进行内存转储并查看 DataTable 实例的绝对数量(!dumpheap -stat -type System.Data.DataTable)然后看看largest data tables in memory。

这是 ASP.NET 应用程序中的一个常见缺陷，可能会给您带来严重的麻烦。如果您使用共享（缓存）数据表实例，请注意视图过滤器会更改原始实例，它们不会生成新副本。

还要确保填充 DataTables 的查询对返回的行数有合理的限制，否则对数据的更改可能会突然增加内存并破坏应用程序池的稳定性。

Answer 5

是的，我会在这里小心...

我必须照顾一个 vb.net 网络应用程序大约 2 个月，然后才能用 C# 重新编写它......我喜欢 C#，VB 让我想投掷......

无论如何，在旧应用程序中，之前的开发人员已将数据库中的数据加载到数据表中，然后将数据表传递给一些对数据表完全没有任何作用的方法，只是将其分配给网格视图。我完全不相信。

更糟糕的是，有时他实际上会无缘无故地将 DataTable 转储到会话中。

DataTables 等很棒，但只有在你“真的”需要使用它们时才使用它们。开发人员太糟糕了，在搜索页面上，他实际上将所有 5000 种产品从数据库中转储到数据表中，然后在数据表上执行搜索，而不是在存储过程中执行搜索（即在 SQL SERVER 上）