我们如何解决所有这些"从类型DBNull转换为类型字符串无效"nastiness？

Question

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

因此,当使用内置的ADO.NET数据集/数据表时,错误:

从类型DBNull到String类型的转换无效

在引用任何旧字符串数据时,在应用程序中稍后会很常见.

这是一个特别的问题,因为它可以很容易地把我们赶出去(而且通常在测试中看不到)

我知道有各种解决方案:

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

但:

• 这是整个应用程序中繁琐的额外几行代码

• 如果我们忘记支票,即使是100次中的一次,我们也有潜在的错误

2.在数据集设计器中,将字段的NullValue属性从默认的"Throw Exception"更改为"Empty"

但:

• 我们必须识别并更改我们添加到数据集设计器的每个表和每个字符串字段(请记住默认值为"Throw Exception")

• 如果我们在100中忘记了一次变化,我们就会潜伏着潜在的错误

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

但:

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

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

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

但:

• 是的,我们确实为我们的"主要"表格做到了这一点.但数据集设计器是一个很好的,快速的方法来提取选项列表或查找表,我们只需要默认的数据行为

5.使用代码生成器或框架,如CSLA而不是DataSet

但:

• 解决一个小问题的重要一步......关于SO标记CSLA的排名最高的问题的第二个答案提到:"它的缺点在于它有一点学习曲线."

Answer 1

这就是为什么数据集和数据表是：

1. 非常适合快速组合使用简单数据访问的应用程序（正如您提到的）。

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

我发现使用正确的数据绑定感知对象模型几乎总是胜过使用 DataSet 和 DataTable，并且它们可以拥有使用 DataSet 和 DataTable 的所有（甚至更多！）功能、易用性和速度。

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

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