为了账号安全,请及时绑定邮箱和手机立即绑定

微服务架构中的Hibernate Join表

微服务架构中的Hibernate Join表

开满天机 2021-05-14 17:10:02
我有两种微服务,一种是用户服务,另一种是产品服务,两者都有自己的数据库产品服务数据库表user_products(id,user_id,product_id)产品(编号,名称)用户服务数据库表User(id, name, ..)用户与产品有着多对多的关系。由于user_products是仅在产品服务中存在的联接表。我不确定如何为产品服务表创建休眠模型对象,以便获得:属于特定用户的所有产品的列表产品所有所有者的列表不确定如何在上面两个表的上方定义@ManyToMany关系
查看完整描述

2 回答

?
哆啦的时光机

TA贡献1779条经验 获得超6个赞

分析您的问题,您是否不认为产品和所有者之间没有多对多的关系。一个产品如何由两个不同的所有者(用户)拥有?通常,电子商务系统中的产品ID标识1个唯一的物理实体。即使有超过1种相似产品(这是实际生产情况),IMO每种产品也将具有不同的产品ID。

但是,让我们考虑一下两个实体相互依赖的不同情况。在这里,出现在图中的概念是有限的上下文

每个服务都应拥有其数据,并应对其完整性和可变性负责。每个服务应独立存在,即具有更改和移入和移出运行时环境的能力,而不会对其他服务产生副作用。

让我们举一个更清晰的公司示例,该公司需要在其员工之间管理Project。我们可以在这里看到两个不同的上下文(现在忽略所有其他与公司相关的处理)

  1. 项目

  2. 员工

如图所示,我们无法在Project实体中直接引用Employee实体。

合适的解决方案是:假设将对象模型映射到关系数据源,而不是Project Service必须映射Employee类型,则它仅必须映射employee id属性。

//img1.sycdn.imooc.com//60a4dec5000167b406010201.jpg

Project_Resource模型的基础映射表不会从数据库中实现Employee对象。为了获得或变异雇员,您将利用来自雇员上下文的雇员服务API调用。

因此,必须引入更多机制来支持这种隔离。具体来说,当通过员工服务删除员工时,其他服务如何知道这种删除?员工服务同步调用产品服务将导致高度耦合。在这种情况下,应该使用异步模式来解耦其他服务(更多地用于发布事件,另一个服务可以决定是否必须采取措施)

下面的博客很好地解释了其他用例和其他解决方案,它们描述了Bounded上下文的使用,并注意了低耦合和促进内聚。 https://hackernoon.com/microservices-bounded-context-cohesion-what-do-they-have-in-common-1107b70342b3



查看完整回答
反对 回复 2021-05-19
  • 2 回答
  • 0 关注
  • 165 浏览

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信