【问题标题】:how to represent relationship value on parent for simple entities如何在简单实体的父级上表示关系值
【发布时间】:2018-01-01 09:19:36
【问题描述】:

这个问题是关于最佳实践和设计模式的; 我确信我可以根据应用选择任何选项,但我想将后端开发为最佳实践,而不管前端应用/客户端当前的需求是什么。

当某个资源与另一个资源具有一对多/多对多关系时,API 开发过程中应遵循的最佳实践是,是否可以将一个资源中的列添加到另一个资源中以表示我确定的重要列需要强制吗?

#Example Database may look like:-
Event{
 id: 1,
 user_id: 1
}
User:{
 id: 1,
 name: 'Momen',
}

现在响应 GET /Post/1

## Option 1
Event{
  id:1,
  user_id:1,
  user:{
   id:1,
   name: momen,
  }
}
## Option 2
Events{
1: Event{
  id:1,
  user_id:1,
  user_name: 'momen',// i will not include User object unless client request it.. but i will inject user_name because it's a data i'm sure that Post will always need
}
}

上面示例中的用户对象可能很大,我不想要整个用户对象,-除非应用程序需要有关用户的更多信息-但我仍然需要他的名字显示在事件列表中。那么是否可以将此名称添加到 Event 对象作为后备,因此如果客户端无法访问其内存中的 User:1,他可以在获取 User 时显示此列。

Q1这是可以接受的还是我正在污染对象并引入异常错误?

在另一种多对多关系的情况下;我有一个想要设置的标志,我应该在父实体上设置它还是必须包含关系对象。

EventUser{
 event_id: 1,
 user_id: 1,
}

添加EventUsers表示一对多关系的链接表,

第二季度。我想设置一个标志下一个事件,指示查询这些事件的用户是否会参加这个事件。

所以在一个 restful-API 中,我可以响应 GET /events/1 请求

## option 1:

Event{
 id:1,
 name: 'Event 1',
 is_going: true
}

## option 2
{
  events:{ 1:{id:1, name:'Event 1'} },
  EventUser:{1:{ event_id: 1, user_id: 1},} // or {} if not going
}

很明显 option1 更易于实现且更易于处理。但这意味着我再次将列引入到不存在的事件模型中。另外,如果客户端要缓存此类结果以供离线优先使用,并且用户更改,则此数据完全是错误的。

【问题讨论】:

    标签: rest design-patterns database-design redux normalization


    【解决方案1】:

    我使用 api 的经验是,我总是获得比我讨价还价的更多的数据,并且对象高度解耦。
    在您的情况下,我会将用户保留为事件下的独立对象数组,并允许过度明确的结果。您始终可以在 api 有效负载中添加一个 fields 可选参数,以便用户可以决定哪些字段是有趣的(在您这边实现 obj_res = _.pick(obj, fields))

    永远不要连接对象,当您的对象随时间变化和增长时,这将导致一场噩梦。耦合不好:)

    【讨论】:

    • 即使在第二种情况下,您也想指出用户是否参加活动(链接表)?
    • 在第二种情况下,答案似乎应该以用户为中心。我会返回一个对象样式 { user : 1234, Attend_event: 9876 }
    猜你喜欢
    • 2021-05-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-12-19
    • 1970-01-01
    相关资源
    最近更新 更多