假设JPA实体(例如)自动生成长ID:
@Entity
@AutoProperty
public class SomeItem {
@Id
@GeneratedValue(strategy=GenerationType.AUTO)
private long Id;
...
}
有没有理由不为此Id生成setter和getter?例如,人们可能不想生成一个setter,因为JPA负责生成ID。
答案 0 :(得分:17)
我看到其他评论误导了你,所以我觉得自己有点不得不详细阐述这个问题,尽管我不能给你一个科学而完整的答案。 @vcetinick写了当前接受的答案:
你可能发现你可能能够从持久性方面逃脱[..]。
这句话特别错。全部取决于您放置@Id
注释的位置。 specification说:
如果实体具有基于字段的访问权限,则持久性提供程序运行时 直接访问实例变量。
因此,您无需以任何方式提供制定者或吸气剂。因为您注释了字段而不是getter方法(注释setter方法将被忽略并且没有方位)。
但是,如果你编写了一个getter方法,并使用@Id注释而不是你的字段注释了这个方法,那么我们会告诉我们的持久性提供者通过访问器访问我们的字段( getter )和mutator( setter )方法而不使用反射。在这种情况下,应该存在两者一个getter和一个setter。第{71}页书写在第71页(粗体标记由我!):
使用属性访问模式时,将应用与JavaBeans相同的合同,并且必须存在持久属性的getter和setter方法。属性的类型由getter方法的返回类型确定,并且必须与传递给setter方法的单个参数的类型相同。 这两种方法都必须是公开的或受保护的可见性。
因此,我通常会注释我的id字段,并编写一个setter和getter方法,但是setter方法我给了受保护的访问权限。我只是不希望任何其他代码片段对这样一个重要的字段有轻松的写入权限。我不知道这是否会导致其他领域出现问题。我不是专家。但是我没有找到任何关于为什么不以这种方式设置id属性的理由。另请参阅Pro JPA 2: Mastering the Java™ Persistence API。
答案 1 :(得分:5)
您可能会发现,如果没有从持久性方面在JPA实体上放置getter / setter,您就可以逃脱。但是,如果您开始处理从其他来源序列化的实体,甚至在某些情况下从您的视图处理,您将需要一种方法来设置实体的ID以让JPA知道它正在处理现有实体,如果您不能设置id,然后持久层将把它当作一个新的对象。
答案 2 :(得分:2)
Id
是您的主键,没有它您永远无法在数据库中插入记录。
在您的情况@GeneratedValue(strategy=GenerationType.AUTO)
中,它确保为每个id
生成persist
,但您还需要一种方法来访问它,因为它是entity
的主要标识,您应该提供对它的访问。
就像你问某个人他的名字一样,他没有把它提供给你,你会觉得他只是粗鲁。