Использование свойств навигации вместо внешних ключей в Domain Driven Design и EF Core

Question

У меня есть доменные объекты, Product (родительский) и ProductPart (дочерний, Product, ProductId (теневой), Name). Их установщики полей идентификаторов являются частными (, потому что идентификаторы пропускают абстракцию ). (Используя EF Core 2.1)

Я меняю название ProductPart и продукта, к которому он принадлежит (через внешний ключ ProductId).

Если мне нужно использовать свойство навигации Product ( linking) лица ) вместо ProductId, тогда я должен загрузить весь продукт из базы данных, что будет избыточным только для идентификатора.

Как я могу использовать свойство навигации (Product) ProductPart вместо внешнего ключа ProductId с оптимальным решением и без взлома поля Id (продукта) по отражению?

public async Task<dbresult> GetOrCreateItemAsync(ProductPartViewModel itemViewModel)
{
    var productPart = await productPartRepository.GetOrCreateByIdAsync(itemViewModel.Id);

    productPart.SetName(itemViewModel.Name);
    // ProductId is Foreign Key
    productPart.SetProductId(itemViewModel.Product.Id);

    var dbResult = await productPartRepository.SaveChangesAsync();
    return dbResult;
}

Answer 1

В домене, управляемом дизайном, все объекты отвечают за свое собственное состояние. С навигационными свойствами и настройками publi c вы нарушаете это. Вы также нарушаете Закон Деметры.

Имея возможность сделать myEntity.OtherEntity.Name = "Arne", вы обходите все свои сервисы и все доменные правила, которые в них проверены.

imho вас не следует путать просматривать модели с объектами домена.

У них совершенно разные цели. Модели представления должны иметь все свои свойства модифицируемыми, чтобы пользовательский интерфейс мог их обновлять, в то время как сущности домена должны иметь частные установщики и осуществлять изменения с помощью методов, чтобы иметь возможность защитить свое внутреннее состояние (инкапсуляцию).

Таким образом, вы на самом деле не используется DDD.