c# - 在实体对象设计中处理 id

Question

一段时间以来，我一直在思考如何处理由数据库分配标识符的对象。

表示表实体的典型对象可能如下所示:

public class Test
{
    public int Id { get; private set; }
    public string Something { get; set; }
}

假设我们想使用这个对象在数据库中插入、检索和更新对象。至于检索和更新我们没有问题，因为 Id 字段总是有一个值。

但是，如果我们要向数据库中插入一个新的Test类型的对象，Id字段仍然需要有一个值。我们可以只使用“0”，因为它不太可能用作数据库键，但这确实不是一个好的设计。

同样，如果我们反转情况并使 Id 属性可为空，则我们可以为尚未由数据库分配标识符的对象使用 null。但是，现在从数据库中检索到的对象可能没有标识符(类设计允许，但数据库设计不允许)

关于如何为这个问题做出好的设计有什么好的想法吗？

Answer 1

如果您将 id 视为在您的应用程序中识别/授予对象唯一性的方式，这应该由数据库处理(除非当然，您有其他方式为对象分配标识符)。

如果不是(例如，它是由业务需求驱动的对象属性)- 0 是否有效/良好的设计值完全取决于这些业务需求。从最终用户的角度来看，0 是有效值吗？

如果您觉得在您的应用程序中设置没有 ids 的对象是有问题的，您总是可以将您的对象属性包装到单独的类中。您基本上只会使用此类来为尚未创建的对象携带参数(创建过程通过数据库插入完成)。一旦插入对象，分配 id 和东西 - 你就可以使用你的常规实体。当 id = 0< 接近时，您的用户会“哦，快!那是什么？” 或“好的..我知道该怎么做。”/?

编辑

这个问题(或者更确切地说是我关于包装参数的回答)让我想起了一个曾经让我吃惊的事实。当 child 出生时，她不存在于系统中，直到她的 parent 正式为她注册并为她分配个人身份号码。所以从技术上讲，没有 id - child 不存在(至少从系统的角度来看)，即使每个人都知道她出生等等。这与数据库/您的应用程序相同 - 没有 id 的对象(数据库无法识别的对象)不存在 - 它只是一组参数。有点奇怪，但我希望我的观点很清楚:)