c# - 过度使用 DataTable 不好吗？

Question

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

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

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

Answer 1

数据表可用于善恶。

可接受的使用

我会发现以下是可接受的数据表或数据行用法:

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，取决于您的应用程序的要求和复杂性。如果没有实际看到一些示例代码，很难说您的团队是否在做正确的事情。

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

Not Acceptable 使用

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

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

相信你的直觉:如果你认为设计很古怪，那很可能是。