本文是小编为大家收集整理的关于对实体类的正确设计。需要建议的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
例如，我有实体类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:所有这些类:User，Comment和更多其他 - POJO.
想法1:需要通过接口或抽象类对此类的逻辑绑定.
点2:我明白，所有实体类都有相同的方法:getId和setId().
想法2:需要避免在所有类中宣布此方法.
我的解决方案:
添加接口BaseEntity:
public interface BaseEntity
{
public long getId();
public void setId(long id);
}
添加所有实体类都必须实现此接口.
结果，我们逻辑连接所有实体类.我们保证每个实体类实现getId()和setId()方法.
但是，此解决方案无法解决多个声明getId和setId的问题.
一个解决方案是创建一般质体类别:
public class BaseEntity
{
private long id;
public long getId() {return this.id};
public void setId(long id) {this.id = id;};
}
所有实体类都必须扩展基数类.
mmmm，听起来不错:)
但是，使用当前实现 - 用户可以创建instanse baseentityClass. 这很有意义吗?我可以提供创建类基础的可能性?
或者，好的解决方案将此类标记为abstract? 你怎么看?
，如果您同意我所有以前的步骤:
我有最后一个问题:
类之间必须基于接口之间的交流.但是我没有实体的接口.将来会给我带来问题吗?
谢谢.
推荐答案
是的，使您的基本实体成为抽象类，并让其他扩展它.
public abstract class BaseEntity
{
private long id;
public long getId() {return this.id};
public void setId(long id) {this.id = id;};
}
作为一般规则，应该始终将其编程到接口而不是实现.
其他推荐答案
您可以使用@mappedSuperClass映射的抽象基础现象类.但是，您仍然必须将ID字段的映射覆盖到每个子类中的适当列.
仅仅因为两个类具有相同的属性，并不一定意味着它们应该扩展一个共同的类.您的代码可能永远不会引用任何具有类型基础的对象.除非您有其他常见方法，否则我建议不要在这种情况下使用超类.它将更简单.
和实体是波约斯.根据我的经验，使用每个实体的接口，只是添加了不必要的复杂性.
其他推荐答案
使质体摘要非常好，我自己以这种方式使用了它.而且我认为您没有什么可以抽象的.如果您有多个具有一些常见列的表格，例如用于审计目的，则可以抽象. 和实体的接口?我不认为这有用.当您必须切换不同的实现实体时，接口更有用.
问题描述
For example, I have entity class User:
public class User
{
private long id;
private String name;
// setters and getters
}
Next, I add new entity class: Comment
public class Comment
{
private long id;
private String comment;
// setters and getters
}
Next, I can add more and more entity classes.
And, at this moment I think: I can/must bind/connect in logical structure my entity classes or no?
What I mean? I try explain:
Point 1: All this classes: User, Comment and more other - POJO.
Idea 1: Need logical binding for this classes via interface or abstract class.
Point 2: I see, that All entity classes has same methods: getId and setId().
Idea 2: Need to avoid declaration this methods in all classes.
My Solution:
Add interface BaseEntity:
public interface BaseEntity
{
public long getId();
public void setId(long id);
}
Add all entity classes must implement this interface.
In result we logical connect all entity classes. And we guarante that each entity class implement getId() and setId() methods.
But this solution doesn't resolve problem with multiple declaration getId and setId.
A solution is to create general BaseEntity class:
public class BaseEntity
{
private long id;
public long getId() {return this.id};
public void setId(long id) {this.id = id;};
}
And all entity class must extends BaseEntity class.
mmmm, sound nice :)
But, with current implementation - user can create instanse BaseEntityClass. This make sense? I can give possibility to create a class BaseEntity?
Or maybe, good solution mark this class as abstract? What do you think?
And if you agree with all my previous steps:
I have last question:
Communication beetween classes must based on Interfaces. But I dont have interface for entities. It is can create problems for me in future?
Thank you.
推荐答案
Yes, make your base entity an abstract class and let other extend it.
public abstract class BaseEntity
{
private long id;
public long getId() {return this.id};
public void setId(long id) {this.id = id;};
}
As a general rule, one should always program to an interface and not to an implementation.
其他推荐答案
You could use an abstract BaseEntity class, mapped with @MappedSuperclass. But you still would have to override the mapping of the ID field to the appropriate column in every subclass.
Just because two classes have the same property doesn't necessarily mean that they should extend a common class. Your code will probably never reference any object with the type BaseEntity. Unless you have additional common methods, I would advise not to use a superclass in this case. It will just be simpler.
And entities are POJOs. Using an interface for every entity, in my experience, just adds unnecessary complexity.
其他推荐答案
Making BaseEntity abstract is perfectly good, I have used it myself this way. And I don't think there's anything else you can abstract. You could abstract if you would have multiple tables that all have some common columns, such as for auditing purposes. And interfaces for entities? I don't think that's anything useful. Interfacing is more useful when you have to switch different implementations, now in entities, that doesn't make much sense.
更多相关问答
联系站长