Как лучше всего обрабатывать общие объекты в Microservice, используя Entity Framework? - PullRequest
Новая
       30

Как лучше всего обрабатывать общие объекты в Microservice, используя Entity Framework?

0 голосов
/ 24 января 2019

У меня есть 2 API микро-сервисов, которые называются User и Order. Поскольку это микросервисы, они оба имеют отдельные DbContext и разные несвязанные сущности. Одним из требований, которые я получил, является список Orders с именем User, который его заказал.

упрощенные сущности похожи на это: 

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
}

Прямо сейчас я могу думать только об одном эффективном подходе, но у него все еще есть недостатки

Получать заказы и отправлять ВСЕ пользовательские идентификаторы на микросервис Пользователя следующим способом: 

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

При моем подходе это не кажется практичным, поскольку когда-нибудь позже требования могут измениться, а также может потребоваться пол пользователя или любая другая информация. Затем мне пришлось бы написать много методов для этих конкретных требований или каждый раз менять свой код. Кроме того, извлечение ALL информации user каждый раз также нецелесообразно, так как потребляет много сетевого трафика.

Существует ли такая лучшая практика для обработки общих сущностей лучше, чем я имею в виду? Или вы думаете, что этот подход все еще достаточно хорош?

Спасибо.

1 Ответ

0 голосов
/ 25 января 2019

Я бы предложил одно из следующего, основанное на четком разделении интересов.Определенно, пользовательский сервис должен отвечать только за любые запросы о пользователях, а сервис заказов должен отвечать за запросы о заказах.Теперь вы можете выполнить одно из следующих действий:

  1. Перед тем, как отправлять запрос о Заказах с идентификаторами пользователей вместо Имен, попросите клиентскую часть сначала запросить идентификаторы пользователя для имен пользователей.Это, вероятно, самое простое решение, но оно немного усложняет бизнес-логику вашего клиента.
  2. Сделайте службу заказа зависимой от службы пользователя.Таким образом, служба заказов получает запрос о заказах по именам пользователей, а затем служба заказов запрашивает службу пользователей, для которых сначала используются идентификаторы пользователей, перед внутренним извлечением заказов.
  3. Представьте третью бизнес-службу, которая отвечает засложные запросы домена и разбивка их на запросы к вашим специализированным службам.Например, отправьте исходный запрос в эту службу, которая затем запрашивает у службы пользователя идентификаторы из имен и использует их для запроса заказов по идентификаторам из службы заказов.Иногда архитекторы предпочитают включать такую ​​логику в пользовательские шлюзы API, которые затем будут действовать в качестве агрегатора.

Обратите внимание, что вызов, который я описал выше, во всех трех решениях для получения идентификатора пользователя по имени, может включать в себя большебольше информации, чем обычный пользовательский API поиска, который также позволяет выполнять поиск по статусу пользователя, возрасту и т. д.

Таким образом, существует множество опций, и в зависимости от требований вашего домена и архитектуры один может быть лучше, чемдругой.

...