• 在对象中保存DB的ID字段,以维持内存对象和DB数据Row之间的identify.
  • 关系DB使用key来区分数据行.
  • 而内存对象不需要这样的键.因为对象系统能够保证身份确认.
  • 读取时没有问题,但是为了正确地写回DB.需要联系两者.
  • 本质上,只是将DB表的主键存储在对象的field上.
• 工作机制
• 键的选择
  • meaningful key.
    • 应保证唯一性和恒定性.
    • 而这种检查是滞后的(Data已经进入DB后才可行).
    • 所以它是不可信的.
  • meaningless key.
    • 由Db构造的,无用的随机数.
• 简单/组合键
• Simple键.只使用一个DB字段.优点是完全一致性(所有的键操作都可以使用相同的代码).
• compound键.使用多个DB字段.
• • • 当一个表与另一表上下文相关时易于使用.
    • 总是有意义的,所以需要注意其唯一性和恒定性.
• 类型
  • 主要的键操作:相等性检查;得到下一个键.
  • 键的大小会影响性能,尤其是有索引时.
• 唯一性
  • 表唯一.在处理继承时比较麻烦.
  • DB唯一.任何一个表的任何一个数据行都是唯一的.好处是可以使用一个单间的标识映射.
• 对象内identify field的表示
  • 最简单的情况是于DB的键相匹配的域.
  • 对于组合键,最好建立一个键类.
• 取得新键
• DB自动生成
• auto-generated field.
• 每当插入一行Data时,该域自增1.
• 问题是难以确定生成的新键的值.
• 所以,对于需要插入关联对象的表不能使用它(插入订单Data时,需要它的键作为订单项目的外键).
• GUID.
• 安全的键.
• 问题是结果串较长.有性能问题.
• • 自己产生
    • 小系统时,(select max)+1.
      • 会锁住整个表.并且需要保证事务间的独立性.否则会多个事务得到同一key.
    • 使用独立的键表.
      • 键表的两列:名称和下一个有效值.
      • DB唯一键.表里只有一行.
      • 表唯一键.Db的每个表对应键表中的一行Data.
      • 对键表的访问,应该置于对其他表插入更新的事务之外的独立事务中.
        • 这样允许一创建内存对象就立刻得到ID.其它业务事务可以立刻使用.
        • 问题是当回滚了插入操作时,操作对应的键就被废弃了.
• 使用时机
• 在内存对象与DB行之间存在映射关系时需要使用identify.通常在领域模型或行数据入口的情况下.

标识域 Identify Field