代码之家  ›  专栏  ›  技术社区  ›  E-A

如何使用实体框架最好地处理微服务中的共享实体?

  •  1
  • E-A  · 技术社区  · 7 年前

    我有两个微服务API User Order . 因为这些都是微服务,所以它们都有 分离 dbContext和Different 无关的 实体。我的要求之一是列出 Orders 名字 用户 是谁命令的

    这个 简化 实体如下:

    public class User
    {
       public Guid UserId {get;set;}
       public string Name  {get;set;}
       //Notice no ORM relations added for Order
    }
    
    public class Order
    {
       public Guid OrderId {get;set;}
       public Guid UserId {get;set}
       //Notice no ORM relations user added. ONLY UserId is returned since this is a microservice and another domain
    }
    

    现在,我只能想一个有效的方法,但仍然有它的缺点

    检索订单并将所有用户ID发送给用户微服务,方法如下:

    public ICollection<Tuple<Guid,string> GetUserNames(ICollection<Guid> userIds)
    {
       //go to the database with ORM and get userId and username as a list
    }
    

    使用我的方法,这似乎不现实,因为有一天,需求可能会改变,用户的性别或任何其他信息可能会被额外要求。然后,我必须为那个特定的需求编写许多方法,或者每次都要更改我的代码。 另外,检索 所有 信息的 user 每次都不实用,因为它会消耗大量的网络流量。

    有没有比我想象中更好地处理共享实体的最佳实践?或者,您认为这种方法仍然足够好吗?

    谢谢。

    1 回复  |  直到 7 年前
        1
  •  1
  •   Oswin Noetzelmann    7 年前

    我将在明确区分关注点的基础上提出以下建议之一。一定要让用户服务只负责任何有关用户的查询,而订单服务则负责有关订单的查询。现在您可以:

    1. 在发送有关使用用户ID而不是名称的订单的查询之前,让客户端先查询用户名的用户ID。这可能是最简单的解决方案,但会使您的客户机对业务逻辑有点负担。
    2. 使订单服务依赖于用户服务。因此,在从内部获取订单之前,订单服务先按用户名获取订单的查询,然后向用户服务询问哪些用户ID是那些用户ID。
    3. 介绍第三个业务服务,它负责复杂的域查询,并将这些查询分解为对您的专业服务的请求。例如,将原始查询发送给该服务,然后该服务从名称中查询用户服务的ID,并使用这些名称从订单服务中按ID查询订单。有时架构师会选择在定制的API网关中包含这样的逻辑,然后这些网关将充当聚合器。

    请注意,我在上面所有三个按名称检索用户ID的解决方案中描述的调用可能包含更多信息,更像是一个通用的用户搜索API,它还允许按用户状态、年龄等进行搜索。

    因此,有很多选择,并且依赖于您的其他领域需求和体系结构,一个可能比另一个更好。