使用类型化的DataSet

mygod

转自我的blog，嘿嘿  http://blog.chinaunix.net/index.php?blogId=1772

mygod | 03 十一月, 2004 18:13

我和很多人的看法一样，那就是DataSet技术可能是.NET中最引人入胜的技术之一，也许很多初学者只是把DataSet用作和DataGrid控件绑定，但是实际上它的有点远不止这些，使用DataSet，你可以使你的应用程序很好的与数据库隔离、使你的应用程序使用最少的SQL、起与数据库连接的无关性在有些场合可以很好的提高效率（比如大数据量查询），可以解决很多让人头痛的数据库问题（比如数据库操作并发问题，还有，实际上如果你使用得当使用DataSet可以很好地解决死锁的问题），还有提供它的XML结构的特性也可以为我们的应用开发带来很多实惠，我想就光讨论DataSet技术的优点和功能我就不得不写很多篇文章，这里我只是打算讨论一下类型化的DataSet的优点。

也许很多朋友要问，DataSet不已经很好用了吗，我们为什么还需要构建自己定义类型的DataSet呢，难道只是为了 将类似这样的代码（Dataset1.Tables["TableName"].Rows[n]["ColumnName"]）改成简洁的代码如：（TypedDataset1.TableName[0].ColumnName）吗？

是的，的确简洁性的确是使用的理由之一，但是不要忘了为了这简洁性，你需要增加若干个自定义的类，这样真的值得吗？

我也许不能找出很多理由来说明使用类型化DataSet的必要性，但是根据我的实际经验，有一点是可以说明它的必要性的，那就是程序的易维护，也就是TypedDataset1.TableName[0].ColumnName 比Dataset1.Tables["TableName"].Rows[n]["ColumnName"]要容易维护，因为在Dataset1.Tables["TableName"].Rows[n]["ColumnName"]里面，如果你写程序的时候把TableName或者ColumnName写错了，当你编译的时候你无法发现错误，只有通过调试才能发现，而调试一直是程序员们最头疼的事情，而TypedDataset1.TableName[0].ColumnName 就不一样了，如果你把TableName或者ColumnName写错了，本身编译就通不过，这样使用类型化DataSet就可能会省掉很多debug的工作；还有，如果是对于系统发生变化，特别是数据库结构发生变化，它的优点就更明显了，如果你的系统很庞大，如果你修改了某个表，那么修改程序以适应这个变化会是个非常让人头疼的问题，也许为了修改一个字段，你要遍历整个系统，作设计然后编码，最后还要测试，而且必须要测试地非常全面才能保证不会有很多bug，但是如果你很幸运地使用了类型化的DataSet，你可以先把改动地表对应的类型化DataSet先修改，然后你可以编译系统，当然会出很多错误提示，根据这些提示，你就可以按图索骥找到所有需要修改的地方（也许你会说我的方法不符合软件工程的要求，不过的确很多情况下你没办法考虑那么多，完成任务才是第一位了）。

所以，我的观点是，我们的应用系统应该大量地使用类型化DataSet，我认为应当为每个表都生成一个，用VS.NET的工具，你甚至不需要写一行代码，就可以“画”出这些类来，更重要的是，你只需要付出这一点额外的工作，就可以省掉很多潜在的debug工作，这才是最重要的了。

好了，今天就到这里。