当你建立一个n层的应用程序时，如何在程序的各个层之间传递消息是至关重要的。许多Windows DNA应用程序利用与现实世界相对应的自定义对象的优点。这些对象包括标量数据类型、数组、集合和记录集（recordset）以及其它基本对象，开发者用这些基本对象来构建应用程序不同层间的调用所需的对象。不过，.NET现在提供了一种自然的、称之为DataSet的对象，它可以表示多个表格（table）以及表格间的关系，其效率远远比在Visual
Studio 6中用自定义对象来表示它们的效率高的多。实际上，通过继承基本的DataSet并通过属性和方法的形式（有关于建立在基本DataSet上的表格的特定知识）来获得“智能”，因此，typed DataSet成为表示事务实体的理想工具。
绝大多数开发者在理论上都认为使用typed DataSet是应用程序不同层间传递数据的好方法，但是当他们尝试把理论应用于实际时，往往发现这并没有像看起来那么简单。
用typed DataSet做为事务实体有两个主要优点。首先，由于typed DataSet已经在设计时解决了所有的内部类型，所以在运行时，typed DataSet在内存中的运行速度一般都要比untyped对象的运行速度要快。其次，由于typed DataSet在小粒度（相对于untyped DataSet）层次上定义数据类型和数据类型间关系，所以你可以在应用程序中的较高层次上跟踪错误。
例如，如果你使用typed DataSet来把CustomerID属性定义为一个长度为5位的数字类型字段（这与底层与之相关的数据库相匹配），那么，如果用户试图在表示层更新CustomerID属性时，typed DataSet会跟踪到这个输入违例。如果你用的是untyped DataSet，那么除非你在每个使用它的地方都添加相应代码，否则在更新底层数据库之前，你都无法跟踪到这个错误。
困扰开发者在开发程序时使用typed DataSet的一个主要问题就是决定使用多少个typed DataSet。例如，如果你想建立一个订货登录系统，那么你是为每一个顾客、订单、发货单、订货项目、发货项目以及产品都建立一个typed DataSet；还是仅仅建立一个DataSet包括所有这些数据库实体（database entity）并用它们间的关系把它们拴到一起？
有些开发者认为通过为每一个数据库实体都建立一个事务实体就可以尽可能的降低对内存的占用并缩短建立事务实体所需的载入时间。但是，他们的这种做法实际上抹杀了typed DataSet最主要的优点（即，在应用程序的最高层次上验证表格间的引用完整性（referential integrity））。
那么该如何在缩短载入时间并降低内存消耗的情况下利用typed DataSet的优点呢？你可以建立一个简单的typed DataSet，然后填充正在执行的操作所需的内容。一般来说，你可以从左至右（from left to right）的载入DataSet。例如，如果你想看看某位顾客的订单和定单项，而又想避免载入typed DataSet时的引用完整性错误，那么你就需要在客户表中提交一个记录，然后在订单表和定单项目表中载入全部的订单和定单项目，往产品表中载入所有出现的产品。不过，如果你只想看看客户清单，那么你只需载入客户表即可。
