记录集的隐式接口与显式接口权衡

记录集是表格数据在内存中的表现方式，专门解决数据相关UI工具”只管显示和简单更新、却没地方放业务逻辑”的问题——领域逻辑代码可以直接生成或操控一个和SQL查询结果长得一样的记录集。大多数记录集实现走的是隐式接口：取数据靠一个通用方法加字段名参数，比如aReservation["passenger"]；对应的显式接口则需要一个真正定义好属性的类，写成aReservation.passenger。作者对隐式接口整体持保留态度——用隐式接口时，想知道某个数据结构到底该用哪个字符串键（是”passenger”还是”guest”还是”flyer”）唯一的办法是翻源码找到这个结构最初是在哪创建的；这个问题在静态类型语言里更严重，因为编译器帮不上忙，想拿到强类型的字段还得写成((Person)aReservation["passenger"]).lastName这种啰嗦的手工类型转换，而显式接口能让编译器保留类型信息，直接写aReservation.passenger.lastName就够了。但记录集这个场景有一点特殊：因为记录集本来就是从SQL查询结果生成的，创建它的那条SQL语句里必然已经写明了列名，所以隐式接口在这里”查起来很困难”这个通病被大大缓解了——这是隐式接口在记录集模式下相对而言的一点优势。即便如此，作者依然推荐优先用显式接口（如ADO.NET的强类型数据集，可以从XSD定义自动生成，还能表达多表关系）；本书示例之所以用无类型数据集，只是因为隐式接口目前更常见，但建议在实际项目里，ADO.NET环境用强类型数据集、其他环境靠自动代码生成来造显式记录集。可迁移启发：判断”通用+隐式”和”专用+显式”两种接口设计孰优孰劣时，要看清楚隐式接口那个”想用什么键得翻源码”的核心痛点，在当前场景下是否已经被别的机制（比如这里的SQL列名本就写在查询语句里）事先缓解了——同一个权衡放到不同场景里，结论可能完全不同。