表模块模式概述
与事务脚本相比，表模块更有结构，因为它提供了更充分的实现指导规范。该模式的规则可以简单总结成如下内容：为每个数据库表定义了一个业务组件。这个业务组件叫做表模块，其中包含操作于该数据表上的所有代码。

表模块类作为一个容器，将数据和行为组合在一起。业务逻辑被拆分为粗粒度的，表示整个数据表的组件。表模块类的粒度不会下降到数据行的程序，即表模块类无法区分一行数据。因此需要以集合的形式看待数据行，并通过键或索引来找到特定的行。

表现层如何与表模块业务逻辑层交互数据的呢？表模块严格基于数据表，因此需要以记录集的形式传递数据，记录集是一个内存中表示表格数据的形式，记录集的结构类似于SQL查询生成的结果。不过也可以通过让记录集支持离线操作来为其提供更丰富的功能，这样就让记录集的行为类似于数据迁移对象。

1，何时使用表模块
通常来说，基于对象的模式能够更加灵活，更好地对领域逻辑建模。对象模型是一个对象组成的图，不过其数据存放在关系型数据库中。抹平面对象和关系型模型之间的差别不啻于一个噩梦，这个问题由来已久，因此才产生了各种专门的O/RM工具。

表模块所处的位置介于事务脚本和基于对象模式（例如，活动记录和领域模型）之间，该模式明确地给出了如何定义业务组件及其与系统其他部分的交互方式。虽然表模块仍旧关注的是方法而不是对象，但已经朝着面向对象迈出一大步。

实际上，若将每个数据表都用一个类表示，并将行为封装到这些类中，那么就已经在使用对象模型了。当然，这些对象可能并不能表示问题的领域，而是表示底层的数据模型。不过对于那些不需要太多抽象，且数据模型和对象模型之间没有太大差异的场景，表模块是非常不错的折衷方案。与事务脚本相比，表模块基于一个概念模型，面不是一大批方法的松散集合。

若系统中的表现层和数据访问层都是基于表状数据结构，那么表模块将是非常好的选择。这时，业务层即可为表现层提供直接可用的数据，有时甚至可以直接通过数据绑定实现。类似地，业务逻辑层也可以与数据访问层直接交换数据，而无需额外重组。

在.NET中，我们通常会使用DataSet。不过特别是在表现层中，使用更加简单的DataTable将有助于减少从业务逻辑层中传入传出的数据量。数据访问层和业务通常会交换DataSet，因为它提供了更灵活的功能，例如，允许批量更新以及多表读写操作等。

2，表模块的优势
表模块并没有比事务脚本复杂很多，不过若完全需要手工构造，那么花费的时间可能要比简单的事务脚本多出很多。模式在提供了更多指导的同时，也意味着我们需要考虑更多的规则——也就是需要编写更多的代码。特别是如果说需要从头编写类似DataSet的类型，那么你对表模块又是什么看法呢？

不过表模块的优势在于各种IDE(例如，微软的Visual Studio)均为其提供了很丰富的支持。

在Visual Studio中都提供了向导来创建数据源。向导将从选择数据库项目开始，引导你完成整个步骤，并自动生成所有必要的代码。借助于内嵌的DataSet设计器，我们可从数据库中挑选数据表，并定义关系和约束。每个表模块类都是根据数据表建模而成，暴露了记录的集合以及操作数据表所用的方法等。至少会提供Fill和GetData方法来基于整个数据表进行查询。

从概念角度来看，表模块的另一个优势在于，无论底层数据源是什么（SQL Server,Oracle等），对于同一些功能都会得到同样的表模块类。若基于Visual Studio创建表模块模型，那么需要修改每个表适配器对象的Adapter属性，从而使用正确的连接方式。若手工实现，那么可以将表模块看做是一个高层次的接口，其中封装了一个额外的，可动态加载的，针对特定数据源的数据加载模块。

3，表模块的劣势
表模块基于对象，但完全由数据库驱动。表模块并不适合于表述复杂的众多实体，特别是当对象模型和数据模型之间有显著差别的时候。

表模块的主要优势是Visual Studio提供了强大的支持，因此实现起来非常简单。不过若考虑到到生成的代码类似于一个黑箱，那么这个优势反而会变成劣势。

当然，表模块这个架构模型并不一定需要和Visual Studio紧密耦合。你的基于表模块的系统可以使用ADO.NET DataSet，也可以不使用，可以使用向导，也可以不使用向导。这样，表模块的好坏大都在于其与Visual Studio的集成。你越是远离自动生成的表模块代码，就会越觉的不方便，并尝试要么升级为基于对象的模式，要么降级为事务脚本。