EF Core 6: могу ли я установить значение сущности из другой таблицы?

В EF нет настоящей магии для этого. Если вам нужна магия, вы, возможно, можете положиться на триггер базы данных для заполнения поля при вставке, но имейте в виду, что вам нужно будет обновить объект из базы данных в EF, чтобы увидеть это значение. Однако я бы рекомендовал воздержаться от этого.

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

Краткий ответ: нет, за исключениями, использующими отношения разделения таблиц, вы можете извлекать значения сущностей из связанных таблиц. Используя модели представлений и проекции, такие как Automapper или Mapperly, это было бы тривиально, поскольку они завершают «работу» по построению выражения запроса Select при чтении, чтобы EF погружался в модель предметной области и извлекал только те поля, которые вы хотите использовать.

Вы можете рассмотреть возможность обновления вашей схемы, включив в нее вычисляемый столбец для получения связанного ContactId, а затем вы можете сопоставить его с сущностью, которая будет обрабатываться как вычисленное значение. (Только для чтения) Вероятно, это будет самый простой способ перенести это свойство в вашу сущность. Это работает аналогично столбцу «Идентификация», просто настройте его как [DatabaseGenerated(DatabaseGeneratedOption.Computed)]. Если вы используете Code-First для управления своей схемой, вам нужно будет настроить выбор идентификатора клиента.

Другой вариант — несопоставленный вычисляемый столбец на стороне клиента, например:

public class MyEntity
{
    // ...

    [NotMapped]
    public int ContactId => Destination?.Hotel.Contact.Id ?? 0;
}

Однако это будет надежно только в том случае, если любое применимое место назначения + отель + контакт будет загружено или предварительно заполнено DbContext или у вас включена отложенная загрузка. (что было бы довольно дорогим свойством для чтения, поскольку для получения этого свойства пришлось бы загружать весь пункт назначения, отель и контакт). Если к свойству обращаются нечасто и его не будут «затрагивать» в таких вещах, как итерации списка, это не является Совершенно ужасная ситуация для ленивой загрузки, но создает ситуацию с миной, которая может вызвать проблемы с производительностью.

«Хакерский» подход с использованием Automapper (или других поддерживаемых IQueryable картографов, таких как Mapperly) заключается в проецировании на отдельные объекты, где вы не работаете с моделями представлений. Подобно несопоставленному вычисленному на стороне клиента значению, приведенному выше, мы используем несопоставленное свойство:

public class MyEntity
{
    // ...

    [NotMapped]
    public int ContactId { get; protected set; }
}

Затем у нас есть конфигурация Automapper. Обычно я помещаю их как статические методы в свои модели представления, но мы можем добавить их к сущности в качестве примера:

    public static MapperConfiguration BuildConfig()
    {
        var config = new MapperConfiguration(config => 
            config.CreateMap<MyEntity, MyEntity>()
                .ForMember(x => x.ContactId, opt => opt.MapFrom(src => src.Destination.Hotel.Contact.Id ?? 0));

); вернуть конфигурацию; }

Затем, читая наши сущности, вставьте ProjectTo<MyEntity> перед ToList() или FirstOrDefault() и т. д., где эта сущность читается:

Т.е.

 var myEntity = context.MyEntities
     .Where(x => ...)
     .ProjectTo<MyEntity>(MyEntity.BuildConfig())
     .ToList();

Недостаток этого подхода заключается в том, что полученные объекты будут отсоединены, поэтому, если вы хотите выполнять обновления, вам нужно будет их присоединить. Это означает, что в первую очередь нужно проверять существующие отслеживаемые объекты. Сущности, считываемые без проекции, не будут иметь доступный ContactId. Вы не можете использовать свойство ContactId для изменения контакта, это необходимо сделать через Destination.Hotel.Contact. Обратите внимание, что изменение этой связи не приведет к автоматическому обновлению ContactId в MyEntity. Вы хотели бы использовать больше подхода DDD к объекту, например «MyEntity.ChangeDestination(Destination)», который обновил бы пункт назначения и повторно вычислил ContactId. Честно говоря, было бы лучше использовать ViewModels, чтобы избежать путаницы и хлопот, которые могут возникнуть из-за отдельных сущностей и несопоставленных свойств. Хотя это вариант, который вы можете изучить.