I inherited a Springboot based piece of software, in which each entity is represented by at least two data types. For example:
The DTO:
@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class MyEntityDTO {
Long id;
String name;
String description;
String type;
Long parentId;
String parentSerialNumber;
}
The corresponding JPA entity (table):
@DiscriminatorColumn(name = "type")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@Table(name = "my_entities_table")
@Entity
@NoArgsConstructor
@Data
@SuperBuilder
@FieldDefaults(level = AccessLevel.PRIVATE)
public abstract class MyEntity extends IdBasedEntity {
@ManyToOne(fetch = FetchType.EAGER)
@JsonIgnore
Parent parent;
@Column(name = "type", insertable = false, updatable = false, nullable = false)
String type;
@Column(nullable = false)
String externalId;
@Column(nullable = false)
String myentityName;
@Column
String description;
}
My question is: What design principles and/or patterns does an abstract JPA entity satisfy?
I am trying to understand this because I was surprised to discover that I cannot mock this entity in a JUnit. I am assuming there is a good design reason for this.
To complete @Chris comment.
According to JPA specification
An entity may inherit from a superclass that provides persistent entity state and mapping information, but which is not itself an entity. Typically, the purpose of such a mapped superclass is to define state and mapping information that is common to multiple entity classes.