POCO 一对一，微型 ORM。我应该存储 ref id 还是只存储 ref 对象？答案

【问题标题】：POCO One-To-One, micro ORM. Should I store ref id or only ref object?POCO 一对一，微型 ORM。我应该存储 ref id 还是只存储 ref 对象？
【发布时间】：2013-06-18 11:02:36
【问题描述】：

当使用像 Dapper 这样的微型 ORM（在存储库中）时，我应该将 ref id 存储到子 Poco 还是只在模型中存储 ref 对象？我认为如果我同时存储两者，更新根对象时会出现同步问题。

例如：

Class Boat
    +Id
    +LakeId
    +Lake

Class Lake
    +Id
    +Name

如果 LakeId 发生一些变化怎么办？湖将处于无效状态！如果有人更改 Lake 并使用 LakeId 怎么办？ LakeId 将处于无效状态。

我认为这两个属性的同步会增加不必要的复杂性。更改 LakeId 需要从 db 获取新的 Lake poco。

您如何在您的项目中处理这个问题（仅使用像 Dapper 或 PetaPoco 这样的微型 ORM）？

【问题讨论】：

标签： repository domain-driven-design poco dapper micro-orm

【解决方案1】：

任何微观结构都只是一个数据映射器。它不关心你写什么 sql，它只是试图将查询结果映射到一个对象。任何插入/更新助手只会让执行该操作更容易，而不会弄乱 sql。

您的担忧与微观无关。您只需在 LakeId 上放置一个外键约束。我真的不明白为什么您同时拥有 LakeId 和 Lake in Boat。您需要先直接获取 db 架构，然后再获取映射查询结果所需的对象 (POCO)。

【讨论】：

一开始我以为每一个entity都要和datatable 1:1映射，每一个fk都应该用entity中的refId来表示。然后我意识到这是不必要的（只需要对实体的引用）。实体属性不必以 1:1 的比例反映表列。事实上，实体甚至不必只对应一个表。