如何检查包含 list 作为数据成员的 2 个对象是否相等?

发布于 2025-01-12 02:31:40 字数 1435 浏览 0 评论 0原文

我在 SpringBoot 中有 2 个实体,即 ProjectFile。这些实体的结构如下所示。

@Document(collection="project")
public class Project{
    
    @Id
    private String id;

    @Field("name")
    private String name;

    @Field("files")
    @DBRef
    @JsonIgnore
    private List<File> files;
}

@Document(collection="file")
public class File{
    
    @Id
    private String id;

    @Field("name")
    private String name;

    @Field("project")
    @DBRef
    private Project project;
}

现在,当我创建 Project 实体的对象,将其保存在数据库中并使用存储库再次从数据库中获取它并尝试使用 equals 方法时,它返回 。 当我单独检查每个属性时,List失败了。 项目中存在的文件。但它会失败是可以理解的,因为 File 类的 equals 方法只有在它的每个数据成员都满足 时才会返回 true >equals 但由于 File 引用了 Project,因此它将失败。 所以这相当于创建一个循环。

如果我将 Projectequals 方法重写为如下所示,它可以工作,但代价是忽略 List。文件

@Override
    public boolean equals(Object obj) {
        if(obj == null)
            return false;
        if(!(obj instanceof Project))
            return false;
        if(this == obj)
            return true;
        Project that = (Project) obj;
        return
            this.id.equals(that.id) &&
                this.name.equals(that.name);
    }

如何在考虑文件列表的情况下解决这个问题?

I am having 2 entities namely Project and File in SpringBoot. The structure of those entity is as given below.

@Document(collection="project")
public class Project{
    
    @Id
    private String id;

    @Field("name")
    private String name;

    @Field("files")
    @DBRef
    @JsonIgnore
    private List<File> files;
}

@Document(collection="file")
public class File{
    
    @Id
    private String id;

    @Field("name")
    private String name;

    @Field("project")
    @DBRef
    private Project project;
}

Now when I am creating an object of Project entity, saving it in database and fetching it again from the database using the Repository and trying to use equals method it is returning false.
When I checked individually for each attribute it was failing for the List<File> files which is present in the Project. But it is understandable that it will fail because the equals method of File class will only return true if each of it's data member will satisfy equals but as the File have a reference to Project, it will fail.
So this is kind of creating a loop.

If I override the equals method of Project to as given below, it works, but at the cost of neglecting the List<File> file.

@Override
    public boolean equals(Object obj) {
        if(obj == null)
            return false;
        if(!(obj instanceof Project))
            return false;
        if(this == obj)
            return true;
        Project that = (Project) obj;
        return
            this.id.equals(that.id) &&
                this.name.equals(that.name);
    }

How to solve this problem taking into consideration of the list of files as well?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

九八野马 2025-01-19 02:31:40

我想说你可以重新审视你的设计。
通常,开发人员在不需要时会创建与实体(或文档)的循环依赖关系。

我假设您的业务案例是以下之一:

A) 文件始终与项目关联(没有文件
没有项目协会)

B) 所有项目至少包含一个文件(没有项目
没有至少一个文件)

C) 可以有没有文件的项目,也可以有没有项目的文件
与之相关。

仅适用于案例 C:
您应该更喜欢循环依赖,并且只有在业务需要时才这样做。

对于案例 A 和案例 B:
您在这里有一个聚合,一个项目及其关联的文件列表(或带有项目的文件)。

“聚合”是领域驱动设计中的一种模式,其中这两个
对象本质上可以被视为一个单元。

此外,当我们从这个角度思考时,这些文档(聚合)也只需要一个存储库。

您可以查看 Pivotal 的演讲,了解有关聚合的更多信息:Talk on Aggregate and Spring数据 JPA,来自 Pivotal

I would say you could revisit your design.
Often developers create circular dependencies with Entities(or Documents) when it is not required.

I assume your business case is one of the below:

A) Files are always associated to a Project (there are no files
without a project association)

B) All Projects contain atleast one File (there are no projects
without atleast one file)

C) There can be projects without files or files without a project
associated to it.

For case C ONLY:
You should be prefering a circular dependency and that too ONLY if business needs it.

For case A and case B:
You have an aggregate here, a project with a list of files associated with it, (or files with project).

"Aggregate" is a pattern in Domain Driven Design, where these two
objects essentially can be treated as a single unit.

Also, when we think in that perspective, there needs to be just one repo as well for these Documents (aggregate).

You can check out this talk from Pivotal for more on aggregates : Talk on Aggregate and Spring Data JPA, from Pivotal

难以启齿的温柔 2025-01-19 02:31:40

您可以重写 equals 方法,并通过在不同的方法中匹配列表对象的 id 来检查列表是否相等。或者也许您可以使用 containsAll() 来检查列表元素是否相等。这不是一个完美的解决方案,但仍然检查列表元素而不是完全忽略它们。

另外,请在此处检查循环依赖项,并尝试以不同的方式构建这些实体:

https:// www.baeldung.com/circular-dependency-in-spring

You can override the equals method and, check for equality of list just by matching the id's of the list objects in a different method. Or maybe you can use containsAll() to check for list elements equality. This is not a perfect solution but still checks for the list elements instead of completely ignoring them.

Also checkout circular dependency here and try to structure those entities in a different way:

https://www.baeldung.com/circular-dependencies-in-spring

心作怪 2025-01-19 02:31:40

尝试仅将 Project.id 保存在文件中。我假设您需要它仅供参考。比较用例,您需要从文件中查找项目或从项目中查找文件并相应保存的频率。

Try to save just Project.id in File. I'm assuming you need that just for reference. Compare the usecase, how often you'll need to find project from file or file from project and accordingly save.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文