【问题标题】:How to do POST on a dependent Entity without a backing Repository如何在没有支持存储库的情况下对依赖实体进行 POST
【发布时间】:2015-01-26 10:35:53
【问题描述】:

我在 Spring Data Rest 设计相关问题的很多答案中都提到了“聚合根”和“实体”以及“值对象”。

我认为存储库等同于聚合根。

案例 1

我的问题是围绕这个,假设有 2 个实体 - User 和 UserSettings ,在数据库中表示为 2 个表,并且 UserSettings 具有指向 User 的外键 user_id。

在这种情况下,我想对 User 和 UserSettings 执行 GET/POST。从一些帖子中,我发现存储库应该处于聚合根级别,这意味着在这种情况下只为用户公开存储库,因为 UserSettings 完全依赖于用户。

现在,我有 2 个具有双向关系的存储库,每个存储库一个,即 UserRepository 和 UserSettingsRepostory ,都作为 REST 服务公开。

因此,我在 UserSettings 和 User as 上进行 POST

/app/userSettings
/app/users

对于,我用于 UserSettings 和用户的 GET -

/app/users/{id}/userSettings
/app/users/{id}

如果我不公开 UserSettingsRepository ,则相当于/app/userSettings 上的 POST,我目前正在执行以下操作 -

Method - POST
Input JSON - {
"user" - "/app/users/{id}",
..
}

案例 2

同样,如果有以下实体/表 - User、UserPost 和 UserComment - 这里 UserComment 有 2 个外键作为 UserPost 和 User。

我想这里我们有 2 个聚合根,因此应该有 2 个存储库作为 UserRepository 和 UserPostRepository。

另一种思考方式是,既然所有都依赖于用户,所以我们只能为 UserRepository 提供 1 个存储库。

这里也是,与我目前的状态相反,我什至有 UserCommentRepository,我不确定一旦删除它如何在 UserComment 上进行 POST。

【问题讨论】:

标签: spring spring-data spring-data-rest


【解决方案1】:

如果您想单独与 UserSettings 交互,它们需要成为专用资源,这意味着它们不再是 User 聚合的一部分。聚合通过确保没有其他人操纵它的部分状态来确保某些断言在其内部保持。所以如果你想做后者,聚合不再是聚合。 Spring Data REST 只是在 HTTP 级别公开这些概念。

要将UserUserSettings 保持在一起,您基本上有两个选择:

  • 通过添加链接为用户资源引入专用状态转换。为指向的资源定义支持的 HTTP 动词和数据结构。
  • 对用户资源使用 HTTP PATCH 操作来操作部分资源。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-04-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-03-10
    • 2017-06-16
    相关资源
    最近更新 更多