Есть ли улучшения в дизайне сущностей в EF Core?

Одной из проблем может быть использование SkuId для PK StockItem. Похоже, что Sku по сути похож на продукт? OrderItem может иметь собственный PK, например OrderItemId, ссылающийся на Sku. Если вы хотите отслеживать уровни запасов (баланс) для Skus, вы можете создать отдельную таблицу/сущность для StockItem/StockLevel, которая может использовать SkuId в качестве PK и FK для Sku.

Набросок для размышления:

public class Order
{
      [Key]
      public Guid Id { get; set; }
      [Required]
      [ForeignKey("CustomerId")]
      public virtual Customer Customer { get; set; }
      //order data

     public ICollection<OrderItem> OrderItems { get; private set; } = new List<OrderItem>();
}

public class OrderItem
{
    [Key]
    public Guid Id { get; set; }
    // order item details. such as Quantity.

    [ForeignKey("OrderId")]
    public virtual Order Order { get; set; }
    [ForeignKey("SkuId")]
    public virtual Sku Sku { get; set; }
}

public class Sku
{
    [Key]
    public Guid Id { get; set; }
    // SKU (product?) fields.
}

public class StockLevel
{
   [Key, ForeignKey(nameof(Sku))]
   public Guid Id { get; set; }
   public uint StockBalance { get; set; }

   public virtual Sku Sku { get; set; }
}

При отображении отношений у меня есть одно предложение: не объявлять свойства FK, а использовать теневые свойства. Это устраняет проблему необходимости поддерживать два источника достоверности, которые могут время от времени различаться и приводить к проблемам поведения в зависимости от того, какой из них вы используете, когда свойство навигации загружено или нет. Отношение между заказом и элементом заказа - один ко многим. В одном заказе много позиций заказа. Свойство обратной навигации (OrderItem.Order) является необязательным, и если оно не нужно, я бы просто удалил его и ссылался на элементы заказа исключительно через совокупный корень заказа. Отношения между OrderItem и Sku являются многими-к-одному. Многие позиции заказа могут относиться к одному и тому же артикулу. Order Item будет иметь Sku ID FK, Sku, как правило, не должен иметь коллекцию OrderItems. Связь для Sku и StockLevel будет один к одному, где SKU является основным в связи, где один StockLevel может ссылаться на него, используя один и тот же PK. Обратите внимание, что в StockLevel столбец Id действует как PK и FK для Sku.

Другое предложение, когда речь идет о коллекциях в сущностях, — всегда инициализировать их. Либо в строке, как в примере выше, либо в конструкторе. С сущностями вы хотите избежать повторной инициализации каким-либо внешним кодом набора связанных сущностей, поэтому Setter делается закрытым. Если бы какой-либо код установил order.OrderItems = new List<OrderItem>();, это довольно легко привело бы к проблемам.

Мы надеемся, что это должно дать вам некоторые идеи по настройке отношений, но не стесняйтесь расширять/комментировать любые конкретные вопросы или сценарии, с которыми у вас все еще есть проблемы.