表模块与表数据入口协作的两种组织方式

表模块要拿到数据，主要有两种组织方式。方式一：让表模块自己包含查询作为工厂方法，直接负责把数据查出来、组装成记录集。方式二：另外配一个独立的表数据入口专门负责查询，表模块只负责在拿到的记录集上跑业务逻辑——代价是设计里多了一个额外的类和相应机制，好处是可以让同一个表模块作用于来自不同数据源的数据（只要为每个数据源各配一个对应的表数据入口即可），实现了”业务逻辑”和”数据从哪来”的解耦。采用表数据入口方式时的典型协作流程是：应用先用表数据入口把数据汇集进一个记录集，再用这个记录集当参数创建表模块（需要多个表模块的行为时，可以用同一份记录集依次创建它们）；表模块在记录集上跑完业务逻辑后，把修改过的记录集传给表现层显示，或交给能感知表结构的界面部件直接编辑——这些界面部件根本分不清记录集是直接来自数据库还是已经被表模块加工处理过；GUI里改完的数据要存回数据库前，还会先经表模块校验一遍。这种分离方式还带来一个额外好处：不需要真实数据库就能测试表模块，只要在内存里手工构造一份记录集即可。虽然”表模块”这个名字暗示每张数据库表对应一个表模块，但实际上表模块的结构更多取决于应用程序能识别的”虚拟表”（比如视图和查询），而不真的绑定数据库表本身的结构，对通用视图或其他查询建立表模块同样有效。

结构图：

flowchart LR
  A["数据获取方式"] --> B["表模块自带查询工厂方法<br/>简单直接，少一个类"]
  A --> C["独立表数据入口负责查询<br/>表模块只处理记录集"]
  C --> D["优点:同一表模块可配<br/>多个数据源的表数据入口"]
  C --> E["优点:无需数据库<br/>内存记录集即可测试"]