二、到底是使用DataSet还是使用商业实体对象
长久以来在.NET领域一直存在着一个争论：是否需要使用DataSet？我们从第一部分的描述已经得知，Dataset在使用上是非常容易的，我们可以通过可视化的设计器来自动生成Dataset，同时将生成处理商业实体数据的API，并且Dataset已经支持很多高级特性了，如变化跟踪、排序、过滤和搜索。而一些反对使用Dataset的人则认为在.Net1.1中的Dataset的性能是非常差的。这些性能问题主要表现在如果数据量非常大时，由于Dataset实质上是已经序列化的XML，因此，如果将XML装载到Dataset中是速度是非常慢的。但这些问题已经在.NET2.0中得到了很大的提高。如果那么.NET1.1的使用者用过.NET2.0的话，也许会有一个全新的看法。
DataSet的另一个用途是使用DataSet创建一个描述商业实体的对象类型，以及包含这些商业实体的集合类型。如果我们这样做，将结束编写大量代码的时代。如果我们在Visual Studio 2005和.NET 2.0中使用code snippets和泛型集合类的话，将会得到更佳的效果。但如果要想发挥DataSet所提供的全部功能，仍然得写很多代码。
定制对象的一个好处是可以按着用户的意愿来控制数据，这主要是由内部暴露出来的API来完成的。对于那些喜欢纯面向对象设计方法的人来说，定制的商业实体将会使它们感到更舒适。在一般情况下，我们可以使用Dataset获得所有用定制商业实体获得的东西，但如果有些数据无法映射成自然的关系模型，那么DataSet就显得无能为力了。当然，如果你只想以获得显示的数据为目的，只允许用户对数据进行增、删、 改操作，那么使用DataSet设计器生成的Dataset还是非常好的。
虽然在Visual Studio 2005中的Dataset支持商业实体的大多数功能。但我们还可以通过扩展类在商业实体中加入更复杂的验证和其他逻辑。每一个Dataset类型（Dataset, Datatable、Datarow和Table adapter）都在生成时都会产生另外一个类，我们可以在这个类中放入自己的代码。这是.Net2.0特有的性质，它允许使用自己的代码来弥补代码产生器的不足，并将自己的代码和自动产生的代码分开，这样做主要是为了防止在重新生成代码时将用户定制的代码覆盖。关于这方面更多的信息，可以参看.NET2.0的MSDN文档。
关于DataSet的另一个争论是如果我们在编写表现层或业务逻辑层时是否应该使用Dataset，当然，有很多人反对这样做，因为这将使这两层和数据绑定得太紧。但事实上并不用这么做，首先，我们应该考虑使用存储过程来降低数据和应用程序之间的耦合度。我们可以很好的将存储过程和应用程序中要使用的商业实体数据很好的工作。另外，如果我们还想用其他方法降低耦合度的话，也可以将Dataset中的数据转换为其他类型的数据或是定制的商业实体数据或直接转换成数据访问层。
最后一个值得争论的东西就是在使用Web Services是，是否通过Dataset来返回数据。大多数人都赞成不使用DataSet返回数据，这是因为，DataSet是.NET专有的，而Web Services是为所以客户端而准备的，也就是说，Java、C++等非.NET语言也可以使用Web Services。这样一来，如果使用Dataset，其他的语言就很难处理数据了。当然，如果客户端是.NET，那么这样做是非常好的。但在一般情况下，客户端可能是任何开发工具，所以笔者建议最好还是不返回DataSet为好。
如果我们想在开发.NET应用中大幅度地提高生产力，就应考虑适当地使用本文所讨论的Dataset。Dataset最大的优点是可以通过Visual Studio 2005产生一个table adapter类，这个类有点象data adapter。设计器允许我们地生成在table adapter中的查询方法，而我们并不用写那么多和ADO.NET相关的代码。为了更好地演示Dataset的功能，下面将给出一个实例来说明Dataset的强大。
如果我们想在开发.NET应用中大幅度地提高生产力，就应考虑适当地使用本文所讨论的Dataset。Dataset最大的优点是可以通过Visual Studio 2005产生一个table adapter类，这个类有点象data adapter。设计器允许我们地生成在table adapter中的查询方法，而我们并不用写那么多和ADO.NET相关的代码。为了更好地演示Dataset的功能，下面将给出一个实例来说明Dataset的强大。
