我们如何解决所有这些“从 DBNull 类型转换为 String 类型无效”的问题？

Question

在我们的应用程序中，我想不出很多我们关心空字符串字段的情况。我们只是希望它们在大多数情况下显示为空字符串。

所以当使用内置的ADO.NET dataset/datatables时，报错：

从类型 DBNull 转换为类型 字符串无效

稍后在引用任何旧字符串数据时在应用程序中太常见了。

这是一个特殊的问题，因为它可以很容易地抓住我们（并且在测试中经常看不到）

我知道有多种解决方案：

1.在所有情况下检查 .IsXXXNull

但是：

• 这是一个乏味的额外几行 整个应用程序的代码

• 如果我们忘记检查，即使 100 次中的 1 次，我们也有 潜伏的潜在错误

2。在数据集设计器中，将字段的 NullValue 属性从默认的“Throw Exception”更改为“Empty”

但是：

• 我们必须识别和改变 每个表和每个字符串字段 我们添加到数据集设计器 （记住默认是“抛出 例外”）

• 如果我们在 100 次中有 1 次忘记更改，我们就有潜在的错误 潜伏

3.避免在基础数据中存储空值

但是：

• 我们必须识别和改变 每个表和每个字符串字段 我们添加到数据库中

• 我们并不总是有那种 控制基础数据

4.不要使用数据集设计器，将数据拉入我们自己的类对象中，在我们自己的代码中处理所有 DBNull 混乱

但是：

• 是的，我们这样做是为了我们的“专业” 表。但是数据集设计器是 很好，快速的方法来拉入一个选择列表 或查找表，我们只在其中真正 需要默认数据行为

5.使用 CSLA 等代码生成器或框架代替 DataSet

但是：

• 解决小问题的一大步...... SO 标记的 CSLA 上排名靠前的问题的第二个答案提到：“缺点是它有一点学习曲线。”

Answer 1

这就是为什么 DataSets 和 DataTables 是：

1. 很好用于快速组合使用简单数据访问的应用程序（如您所述）。

2. 不好对于设计良好的企业应用程序 - 有太多的简化和概括。

我发现使用适当的数据绑定感知对象模型几乎总是胜过使用 DataSets 和 DataTables，并且它们可以拥有使用 DataSets 和 DataTables 的所有（以及更多！）功能、易用性和速度.

而且您不会遇到此类问题，因为您的业务模型并未与数据库结构紧密耦合。

我还没有遇到使用过 CSLA.NET 这样的框架并想回到 DataSets 和 DataTables 的人。

Answer 2

5. （或者可能是 4b）

在您的数据访问类中使用为您提供 NULL 功能的框架。前面提到的 CSLA.NET 框架（由 Riko 编写）使用 SafeDataReader 类，它的工作方式与 DataReader 完全一样，但可以将所有 NULL 转换为空值，以供您的数据访问和业务逻辑层使用。