在 VB.Net 项目中使用强类型数据集答案

【问题标题】：Using Strongly typed DataSet in VB.Net Project在 VB.Net 项目中使用强类型数据集
【发布时间】：2011-11-30 12:24:45
【问题描述】：

使用强类型数据集很好。

目前我正在开发一个在 Visual Studio 2010 中使用 VB.Net 开发的项目。

以前他们使用 Sql 查询直接进入 System.Data.SqlClient 的 SqlCommand，但后来我将所有内容转移到强类型数据集并开始在每个地方使用 TableAdapters..

现在我只想问，这种方式对项目有好处吗... 或者我应该使用 Just SqlCommands 切换回旧的

或者有什么方法可以很好地制作 Sql 数据库，因为它是一个 ERP 并且大部分代码都是用于数据访问的..

【问题讨论】：

标签： sql vb.net visual-studio-2010 sql-server-2008 strongly-typed-dataset

【解决方案1】：

我们现在一直使用强类型数据集。

在转向这种行为之后，在代码中使用 SQL 查询而不是让表适配器完成它感觉非常糟糕。但是数据集有一点开销，所以我猜展位方式适用于不同的解决方案。

对所有字段名都有智能真是太好了，如果您更改 tableadapter 使其返回不同的东西，您会在需要更改代码以反映更改的任何地方遇到设计时错误，而不是在客户发现运行时正在运行程序。

强类型数据集有很多成功的东西，所以我永远不会回去。

【讨论】：

但是当你看到强数据类型的代码文件时，它有近 50,000 行代码，仅 20 个 tableadapter.. 这很好吗，有人告诉我强类型数据集执行时间很长因为它对所有东西都进行类型转换
对我来说，这种开销与我使用它的功能无关。我有包含 40-50 个数据集的 web 服务项目，可以处理服务器和客户端之间的所有数据，而不会出现任何性能问题。但一切都是关于你有什么需要。当然，在某些情况下，数据集不是解决方案。但是，如果您因为开销而不使用数据集，则可能是其他问题...
我绝不建议在性能真正成为问题之前担心性能。你可以花 6 个月的时间编写代码，在一个滴答而不是一毫秒内执行，但用户真的会注意到任何不同吗？故事的寓意——如果它有更好的实践并且更容易维护而没有巨大的开销，那就这样做吧。

【解决方案2】：

表适配器 .... 对更大的数据库造成很多混乱，更新表结构也会导致混乱。我建议为 CRUD 操作使用一些自动代码生成器。对我来说，您的旧模式看起来比完全切换到表适配器和强类型数据集更好。

【讨论】：

在源代码中到处都有 sql 查询时更新表结构是一个更大的痛苦。它关于纪律。更改表，打开 DS 并更改 tableadapter，然后修复受影响的位置（您会在错误窗口中看到所有内容）。旧方法：更改表，转到源代码并尝试查找所有受影响的查询，遗漏一些，然后尝试查找所有使用字段的地方，遗漏一些。找出程序何时运行，最坏的情况是客户找到它，而不是你。有时愚蠢的程序员会使用 row.fields(0) 而不是字段名，搜索这些真的很有趣..

【解决方案3】：

如果您想通过网络将数据移动到其他平台（silverlight、Web 服务、wcf 服务等），那么使用任何类型的数据集都会让您陷入困境。

我们解决这个问题的方法是让类的属性列表与数据库完全匹配。为了将数据移入和移出数据库，我们使用反射来匹配存储过程参数或生成动态 SQL 语句，具体取决于环境和平台。

当更改数据库表时，进行更改的开发人员还负责更新类结构，反之亦然。

为了减少所需的手动编码量，我们使用 CodeSmith 的代码生成功能从数据库生成类，并创建需要字段枚举的标准添加/更新存储过程的基本实现。

作为一个额外的好处，这种方法消除了数据库和业务对象结构之间的紧密联系。我们能够针对 SQL Server、Oracle、Sqlite 和 SqlServerCE 数据库使用相同的数据访问代码和业务对象类。此代码用于在 Windows、PocketPC、Web、iPad 和 Android 应用程序中创建应用程序；所有移动应用程序都使用特定于平台的本地数据库，但使用通用数据访问代码。

最初的设置工作量更大，但从长远来看，它会带来可观的收益。

【讨论】：