知识卡片

行数据入口与表数据入口的选择逻辑

结构图卡

内容

把SQL从领域逻辑中剥离出来、放进独立的”入口”类，是清晰分离数据库访问代码的明智之举——这样应用其余部分完全不用了解任何SQL细节，专攻数据库的开发者也能一眼找全所有数据库访问点。入口主要有两种组织方式：行数据入口对查询返回的每一行产生一个对应实例，是”用面向对象方式看待数据”的直观做法；表数据入口对每个数据库表只用一个对象来管理，提供查询方法并返回记录集这种通用的表格式数据结构。表数据入口与记录集天然匹配，因此是使用表模块时的当然选择，也是组织存储过程访问的合适模式——可以把一整套存储过程集合看作是某张表的表数据入口，必要时再用一个内存中的表数据入口包装存储过程调用，把调用机制封装起来。即使在简单应用中，也值得用某种入口模式把SQL和领域逻辑分离开来，这个收益不取决于应用规模。

结构图：

flowchart TB
  A["数据入口(把SQL从领域逻辑剥离)"]
  A --> B["行数据入口<br/>每行一个实例<br/>面向对象视角"]
  A --> C["表数据入口<br/>每表一个对象<br/>返回记录集"]
  C --> D["天然契合表模块"]
  C --> E["可封装存储过程集合"]

参考来源

- 位置：《企业应用架构模式》第一部分"表述"之"第3章 映射到关系数据库"之"3.1 架构模式"（源文件：_epub-src/OEBPS/Text/000017.html） - 结论依据：原文说明"基于这些原因，把SQL访问从领域逻辑中分离出来，并把它放到独立的类中，实在是明智之举……最显而易见的是为查询语句返回的每一行产生一个它的实例……这种行数据入口……许多环境提供记录集……这种表数据入口……提供了查询数据库的方法，返回一个记录集""表数据入口与记录集非常匹配，这使得它们成为使用表模块的当然选择。它也是一个组织存储过程的模式"，直接支撑本卡结构图。 - 原始内容：即使对于简单的应用程序，我也倾向于使用一种入口模式，浏览一下我的Ruby和Python脚本就可以看到这一点。清晰的SQL和领域逻辑分离是相当有益的。