代码之家 › 专栏 › 技术社区 › Justin Rusbatch

数据表的过度使用是否有害?

asp.net c#

Justin Rusbatch · 技术社区 · 15 年前

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

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

如果有的话,这看起来不太好。这是我应该担心的事情吗?还是我只是过于关注细节?假设你是比我经验最丰富的开发人员,如果有人刚被指派帮助你的站点,就这个“问题”与你联系,你会有什么感觉或反应?

5 回复 | 直到 9 年前

Juliet 15 年前

数据表可以用于善恶。

可接受使用

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

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"]; } }
    // ...
}

上面的课是好啊因为它将数据行映射到类型安全类。现在您有了真正的数据类型和IntelliSense来帮助您,而不是使用字符串和非类型化数据行。此外,如果数据库架构发生更改,则可以修改对象中的列名,而不是在其使用的任何位置修改列名。最后,您可以将难看的列名(如“dtaccount\u created”)映射到名为“accountcreated”的属性。

当然,实际上没有好的理由编写这个包装类,因为Visual Studio将自动生成 typed datasets 为你。或者,作为一种选择,像nhibernate这样的好ORM允许您定义类似于上面的类。

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

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

不可接受的使用

不幸的是,我见过程序员使用数据表来存放特殊的容器、类的替代品等。如果你看到你的团队这样做,就向他们扔石头。这种类型的编程在静态类型语言中不起作用,它将使开发成为一场噩梦。

数据表的主要问题是:它们不是类型化的,所以如果不给它们一个字符串并将它们包含的任何神秘对象强制转换为正确的类型,就无法对它们执行任何有用的操作。此外,重构列名几乎不可能实现自动化,因为它们是基于字符串的,因此您不能依赖IntelliSense来帮助您编写正确的代码,也不能在编译时捕获错误。

我说,相信你的直觉:如果你认为设计是片状的,那很可能是片状的。

Community CDub 8 年前

这绝对是你应该担心的事情-看相关的帖子 on the importance of Disposing DataTables .

数据表 可终结的 :如果您没有主动地处理它们,它们会比gen0集合和内存消耗时间长得多。

为了测量应用程序中的损坏程度,可以使用windbg进行内存转储,并查看大量的数据表实例。 (!dumpheap-stat-type system.data.datatable )那么看看 largest data tables in memory .

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

另外,请确保填充数据表的查询对返回的行数有一些合理的限制,否则对数据的更改可能会使内存突然减少,并使应用程序池不稳定。

Charles Bretana 9 年前

在一个非常高的层次上,软件系统体系结构可以被描述为使用几种“企业级模式”中的一种。 Transaction script , Table Model , Domain Model 或 Service Layer . 如果您正在查看的系统正在使用 表格模型 模式,那么您将期望看到更多的数据表和数据集的使用,而不是在一个使用 领域模型 或者其他模式之一。

然而,随着软件系统设计方法学在过去几年的发展,人们普遍认为使用事务脚本或表模型体系结构的复杂系统运行不佳。这通常是因为在使用这些模式设计的系统中,功能通常更相互交织和相互关联,并且随着复杂性的增加,功能或模块依赖性的数量呈指数增长,并且变得难以快速管理。因此,根据特定系统的复杂程度,是的,如果在系统的多个层中使用数据集和/或数据表,则应该是可疑的。这可能是系统设计者(有意识地或无意识地)使用表模型的迹象,他/她应该使用域模型或服务层体系结构。

Dalbir Singh 15 年前

是的,我会小心的…

我花了大约2个月的时间来处理一个vb.net Web应用程序,然后才能用C语言重新编写它。我喜欢C,vb让我想投掷…

无论如何,在旧的应用程序中,以前的开发人员已经将数据从数据库加载到一个数据表中,然后将数据表传递给几个方法,这些方法对数据表完全没有任何作用,只是将其分配给了一个GridView。我完全不相信。

更糟的是,有时他会将数据表转储到会话中…完全没有理由。

数据表等是很好的,但只有当你“真的”需要使用它们时才使用它们。开发人员很糟糕,在搜索页面上,他实际上将数据库中的5000个产品全部转储到一个数据表中,然后对该数据表执行搜索,而不是在存储过程中执行搜索(即在SQL Server上)。

stoogots2 15 年前

使用数据表可能是一种懒惰/低效的数据存储方式。这样做有很大的开销。你有权担心,尽管开发者可能会有一个真正的问题,听说他们设计这个应用程序有多糟糕。你的目标是创造一个更优质的产品,管理层会支持你吗?他们能接受相关的开发延迟吗?