在大多数情况下，我正在处理的应用程序处理对象，我可以毫无问题地将对象列表绑定到网格视图。
但是，在某些情况下，我想在 gridview 中显示多表连接的结果。当前代码使用数据集，这很容易，但我想知道是否有更好/更有效的方法来做到这一点。
我们不需要数据集的大部分特性——数据是只读的，大多数情况下不会有大量记录。 （即可能不超过 200 个，通常为 10-20 个）
【问题讨论】：
标签： gridview dataset asp.net-2.0
我认为您应该尽可能使用 DataReader。有时 DataSet 更合适，例如下面列出的两种情况。这些来自文章“Why I Don't Use DataSets in My ASP.NET Applications”。另请查看后续文章“More On Why I Don't Use DataSets in My ASP.NET Applications”。
在桌面上，WinForms 应用程序。考虑基于桌面的 数据输入型程序。用户可能 启动程序，加载销售 来自某个数据库服务器的数据，制作 一些更改，然后想保存 这些变化。这是一个理想 数据集的情况。它允许 要读入 DataSet 的数据 驻留在客户端的内存中， 使用户能够工作 在数据上，而不需要 不断地返回 数据库。完成编辑后 数据，他们可以进行批量更新， 优雅地处理任何改变 可能发生在用户 处理数据 断开状态。此外，由于 DataSet 是断开连接的数据 存储，这些数据可以离线使用。 一位推销员前往客户的 网站可以加载这些数据并能够 一边查看笔记本电脑上的数据 在运输途中，或在客户处 办公室。
用于发送/接收远程数据库信息或允许 异类之间的交流 平台。由于 DataSet 可以 序列化/反序列化为 XML 所以 很容易，他们是主要候选人 跨物理发送信息 边界或作为一种手段 将数据序列化为 平台中立的格式。例如， 如果要返回数据库数据 从 Web 服务，一种选择是 只需将数据库数据读入一个 DataSet 然后返回 DataSet 从 Web 服务方法。这 数据集将自动 序列化为 XML 并通过 金属丝。 （个人不推荐 从 Web 服务返回数据 这种方式。相反，我更喜欢使用 自定义业务对象 - 它允许 对 XML 的更精细控制 序列化，提供了一个更轻的 返回有效载荷，并且看起来更少 特定于架构。
【讨论】：