Question

我正在为Web应用程序创建模型。这些表将ID字段作为主键。我的问题是，是否应该将ID定义为类的属性？

我对这个问题存在分歧，因为我不清楚我是否应该将该对象视为表结构的表示，或者我是否应该将该表视为持久保存该对象的方法。

如果我采用前一个路由，那么ID就成了属性，因为它是数据库表结构的一部分，但是如果我采用后一种方法，那么ID可以被视为属于数据库的元数据的一部分，而不是严格地说是对象模型的一部分。

然后我们到达中间地带。虽然ID实际上不是我正在尝试建模的对象的一部分，但我确实意识到对象是从数据库中检索并持久保存到数据库中的，并且数据库中对象的ID对于许多操作至关重要。系统因此包含它以简化使用ID的交互可能是有利的。

我是一名独唱开发者，所以我真的很喜欢其他一些可能在这个问题上更有经验的观点

Answer 1

基本上：是的。我使用的所有持久性框架（包括Hibernate，Ibatis）都需要ID在Object上。

我理解您对元数据的观点，但是数据库中的对象应该以与数据库相同的方式实际派生其身份 - 通常是int主键。那么对象级相等应该从中派生出来。

有时您拥有复合的主键，例如名字和姓氏（不要这样做！），在这种情况下，主键不会成为“元数据”，因为它是Object的标识的一部分。

我通常会保留数据库对象的ID列。我的意见是，要将它用于任何“面向客户”的目的（例如，使用主键ID作为客户编号），您将总是在以后拍摄自己。

Answer 2

如果您对现有数据进行了更改（而不是专门添加新数据），则需要PK。否则，您不知道要在DB中更改哪条记录。

Answer 3

您应该在对象中拥有ID。这很重要。

最简单的用例是测试相等性：

public bool Equals(Object a, Object b) {  return {a.ID = b.ID}; }

其他任何内容都会出错，当您开始收到主要密钥或开始覆盖现有数据时，您会发现这些错误。

通过反驳：

假设您没有对象中的ID。一旦你更改了一个对象，并且没有来自数据库的ID，你怎么知道要更新哪个记录？

同时，您应该注意到我提到的操作对于对象实例是非常私有的，因此ID不一定必须是公共属性。

Answer 4

我将ID作为属性包含在内。无论对象是否持久存储在数据库中，拥有对象的简单唯一标识符通常都非常方便。它还使您的数据库查询更加简单。

我会说这个表只是一个持久化对象的方法，但这并不意味着该对象不能有ID。

Answer 5

我非常注重表格是一种持久保存对象的方法，但即便如此，我总是在我的对象上公开ID有两个主要原因：

数据库ID是唯一标识对象的最方便的方法，无论是在类中（如果您使用的是每个表的序列号/自动编号ID），还是普遍的（如果您要保持单独的“ ID到类“映射”。在Web应用程序的上下文中，如果表单只能指定<input type=hidden name=id value=12345>而不必提供多个字段，这些字段共同包含足够的信息来标识目标对象，那么它会使一切变得更加简单和高效（或者更糟糕的是，使用一些方案将足够的识别信息连接到一个字符串中，然后在提交表单时将其分解回来。
无论如何，它需要有一个ID才能维护一个理智的数据库结构，并且没有理由不来公开它。

Answer 6

对象中的ID是否应该是只读的？在我看来，它应该是只读的，因为根据定义，ID永远不会改变（因为它唯一地标识数据库中的记录）。
这会在您创建新对象（尚未设置ID）时产生问题，通过存储过程将其保存在数据库中，该存储过程将返回新创建的ID，如果ID属性为只读，如何将其存储回对象中？

例：
员工员工=新员工（）;
employee.FirstName = “约翰”;
employee.LastName = “Smith” 的;

EmployeeDAL.Save（雇员）;

如果此属性是只读的，那么Save方法（实际连接到数据库以保存新员工）如何更新Employee对象中的EmployeeId属性（这应该是因为EmployeeId在创建后永远不会更改）。