非面向对象
您不能仅仅因为 DataSet 是对象，而 C# 和 Visual Basic .NET 是面向对象 (OO) 的语言就能以面向对象的方式使用 DataSet。OO 编程的“hello world”是一个典型的 Person 类，该类又是 Employee 的子类。但 DataSet 并没有使此类继承或其他大多数 OO 技术成为可能（或者至少使它们变得自然/直观）。Scott Hanselman 是类实体的坚决支持者，他做出了最好的解释：
“DataSet 是一个对象，对吗？但它并不是域对象，它不是一个‘苹果’或‘桔子’，而是一个‘DataSet’类型的对象。DataSet 是一只碗（它知道支持数据存储）。DataSet 是一个知道如何保存行和列的对象，它非常了解数据库。但是，我不希望返回碗，我希望返回域对象，例如‘苹果’。”1
DataSet 使数据之间保持一种关系，使它们更强大并且能够在关系数据库中方便地使用。不幸的是，这意味着您将失去 OO 的所有优点。
因为 DataSet 不能作为域对象，所以无法向它们添加功能。通常情况下，对象具有字段、属性和方法，它们的行为针对的是类的实例。例如，您可能会将 Promote 或 CalcuateOvertimePay 函数与 User 对象相关联，该对象可以通过 someUser.Promote() 或 someUser.CalculateOverTimePay() 安全地调用。因为无法向 DataSet 添加方法，所以您需要使用实用程序功能来处理弱类型对象，并且在整个代码中包含硬编码值的更多实例。您一般会以过程代码结束，在过程代码中，您要么不断地从 DataSet 中获取数据，要么以繁琐的方式将它们存储在本地变量中并向其他位置传递。两种方法都有缺点，而且都没有任何优点。
与 DataSet 相反的情况
如果您认为数据访问层应返回 DataSet，您可能会漏掉一些重要的优点。其中一个原因是您可能正在使用一个较薄或不存在的业务层，除了其他问题外，它还限制了您进行抽象的能力。另外，因为您使用的是一般的预编译解决方案，所以很难利用 OO 技术。最后，Visual Studio.NET 等工具使开发人员无法轻松地利用弱类型对象（例如 DataSet），因此降低了效率并且增加了出错的可能性。
所有这些因素都以不同的方式对代码的可维护性产生了直接的影响。缺乏抽象使功能改善和错误修复变得更复杂、更危险。您无法充分利用 OO 提供的代码重新使用或可读性方面的改进。当然还有一点，无论您的开发人员处理的是业务逻辑还是表示逻辑，他们都必须非常了解您的基础数据结构。
返回页首
自定义实体类
与 DataSet 有关的大多数问题都可以利用 OO 编程的丰富功能在定义明确的业务层中解决。实际上，我们希望获得按照关系组织的数据（数据库），并将数据作为对象（代码）使用。这个概念就是，不是获得保存汽车信息的 DataTable，而是获得汽车对象（称为自定义实体或域对象）。
在了解自定义实体之前，让我们首先看一看我们将要面临的挑战。最明显的挑战就是所需代码的数量。我们不是简单地获取数据并自动填充 DataSet，而是获取数据并手动将数据映射到自定义实体（必须先创建好）。由于这是一项重复性的任务，我们可以使用代码生成工具或 O/R 映射器（后文有详细的介绍）来减轻工作量。更大的问题是将数据从关系世界映射到对象世界的具体过程。对于简单的系统，映射通常是直接的，但是随着复杂性的增加，这两个世界之间的差异就会产生问题。例如，继承在对象世界中是获得代码重新使用以及可维护性的重要技术。不幸的是，继承对关系数据库来说却是一个陌生的概念。另外一个例子就是处理关系的方式不同：对象世界依靠维护单个对象的引用，而关系世界则是利用外键。
因为代码的数量以及关系数据和对象之间的差异不断增加，看起来这个方法并不太适合更复杂的系统，但事实正好相反。通过将各种问题隔离到一个层中，即映射过程（同样可以自动化），复杂的系统也可以从此方法获益。另外，此方法已经很常用，这意味着可以通过几种已有的设计模式彻底解决增加的复杂性。前面讨论的 DataSet 的缺点在复杂系统中将成倍扩大，最后您会得出这样一个系统，它欠缺灵活应变能力的缺点恰好超出其构建的难度。
看下这段话 或许明白偶 尽量不用DataSet的原因
什么是自定义实体？
自定义实体是代表业务域的对象，因此，它们是业务层的基础。如果您有一个用户身份验证组件（本指南通篇都使用该示例进行讲解），您就可能具有 User 和 Role 对象。电子商务系统可能具有 Supplier 和 Merchandise 对象，而房地产公司则可能具有 House、Room 和 Address 对象。在您的代码中，自定义实体只是一些类（实体和“类”之间具有非常密切的关系，就像在 OO 编程中使用的那样）。