正确设计实体类。 需要建议

例如,我有实体类User

 public class User { private long id; private String name; // setters and getters } 

接下来,我添加新的实体类: Comment

 public class Comment { private long id; private String comment; // setters and getters } 

接下来,我可以添加越来越多的实体类。

而且,此时我想:我可以/必须在逻辑结构中绑定/连接我的实体类还是没有?

我的意思是说? 我试着解释一下:

第1点:所有这些类: UserComment等 – POJO

想法1:需要通过接口或抽象类对这些类进行逻辑绑定。

第2点:我看到,所有实体类都有相同的方法: getIdsetId()

想法2:需要避免在所有类中声明此方法。

我的解决方案

添加接口BaseEntity

 public interface BaseEntity { public long getId(); public void setId(long id); } 

添加所有实体类必须实现此接口。

结果我们逻辑连接所有实体类。 我们保证每个实体类都实现getId()setId()方法。

但是这个解决方案并没有解决多个声明getIdsetId

解决方案是创建一般的BaseEntity类:

  public class BaseEntity { private long id; public long getId() {return this.id}; public void setId(long id) {this.id = id;}; } 

并且所有实体类都必须扩展BaseEntity类。

mmmm,听起来不错:)

但是,使用当前实现 – 用户可以创建instanse BaseEntityClass。 这有道理吗? 我可以创建一个BaseEntity类吗?

或许,好的解决方案将此类标记为abstract ? 你怎么看?

如果您同意我以前的所有步骤:

我有上一个问题:

类之间的通信必须基于接口。 但我没有实体接口。 它可以在将来给我带来麻烦吗?

谢谢。

是的,使您的基本实体成为一个抽象类,让其他实体扩展它。

 public abstract class BaseEntity { private long id; public long getId() {return this.id}; public void setId(long id) {this.id = id;}; } 

作为一般规则,应始终编程到接口而不是实现。

您可以使用与@MappedSuperclass映射的抽象BaseEntity类。 但是您仍然必须覆盖ID字段到每个子类中相应列的映射。

仅仅因为两个类具有相同的属性并不一定意味着它们应该扩展一个公共类。 您的代码可能永远不会引用BaseEntity类型的任何对象。 除非你有其他常用方法,否则我建议不要在这种情况下使用超类。 它会更简单。

实体是POJO。 根据我的经验,为每个实体使用接口只会增加不必要的复杂性。

使BaseEntity抽象非常好,我自己也用这种方式。 我不认为你还有什么可以抽象的。 如果您有多个表都有一些公共列,例如出于审计目的,您可以抽象。 和实体的接口? 我不认为这有用。 当你必须切换不同的实现时,接口更有用,现在在实体中,这没有多大意义。