如何表示简单实体的父级关系值

此问题涉及最佳实践和设计模式; 我确定我可以根据应用选择任何选项，但是我希望开发后端以适应最佳实践，而不管前端应用/客户端当前的需求是什么。如何表示简单实体的父级关系值

在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 
} 
}

在上面的例子中用户对象可以是巨大的，我不希望整个用户对象，-unless应用程序需要更多的信息关于用户 - 但我仍然需要他的名字才能显示在事件列表中。所以可以将此名称添加到Event对象作为后备，因此，如果客户端无法访问用户：1在他的内存中，他可以在获取用户时显示此列。

Q1这是可以接受的，或者我是污染对象和引入不一致的错误？

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

EventUser{ 
event_id: 1, 
user_id: 1, 
}

添加EventUsers链接表格，它表示一个一对多的关系，

Q2。我想设置一个标志下一个事件，指出查询这些事件的用户是否要参加这个事件。

所以在一个宁静的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 
}

其明确表示，选项1是更容易实现，更容易处理..但再次声明，我介绍这意味着列到不存在的事件模型。此外，如果客户端要将这些结果缓存为脱机优先使用和用户更改，那么这些数据根本就是错误的。

来源

2017-07-26 Zalaboza

我对API的使用经验是，我总是获得更多的数据，然后我讨价还价，并且对象高度分离。
在你的情况下，我会保持用户在事件下的独立对象数组，并允许显式结果。您可以随时在API有效载荷增加领域可选参数，以便用户可以决定（实施obj_res = _.pick（OBJ，场）就在你身边）

从不将对象哪些字段是有趣的，那当你的物体随着时间的推移而变化和增长时，将会导致一场噩梦。耦合不好:)

来源

2017-07-26 07:47:13

即使在第二种情况下，你想表明用户是否参加一个事件（链接表）？ – Zalaboza

在第二种情况下，答案似乎应该是以用户为中心的。我会返回一个对象样式{user：1234，attending_event：9876} –

如何表示简单实体的父级关系值

回答

相关问题