Как я могу сопоставить свойство с экземпляром класса в ядре entity framework?

У меня есть класс

public class MyEntity
{
    public IDateTimeProvider DateTimeProvider { get; }

    public MyEntity(IDateTimeProvider dateTimeProvider)
    {
        DateTimeProvider = dateTimeProvider;
    }

    protected MyEntity()
    {
    }
}

Когда я сопоставляю это с DbContext, я хочу, чтобы он игнорировал этот столбец (поскольку это не примитивный тип). Когда он загружается из базы данных, я хочу, чтобы он заполнил этот столбец экземпляром DateTimeProvider.

Кто-нибудь знает как это сделать?

Я хочу сказать что-то вроде:

modelBuilder
    .Entity<MyEntity>()
    .Property(x => DateTimeProvider)
    .Ignore()
    .OnLoadInject(new DateTimeProvider());

Я думаю, что вы делаете ошибку дизайна ... Сущность должна иметь только свойства, сопоставленные с таблицей БД.

OrcusZ 11.04.2018 13:50

@OrcusZ: нет, у вас есть доказательства, подтверждающие это утверждение, или это просто субъективное мнение?

Wiktor Zychla 11.04.2018 13:53

@ chris31389: Почему у вас нет конструктора без параметров, который просто устанавливает значение?

Wiktor Zychla 11.04.2018 13:54

@WiktorZychla Игнорировать работу. Для Провайдера IServiceCollection можно получить с помощью BuildServiceProvider(). Но я думаю, что это ошибка дизайна - иметь такой вид непосредственно в сущности.

OrcusZ 11.04.2018 14:00

Даже входящий 2.1 внедрение конструктора сущности не поддерживает это - Поддержка внедрения сервисов приложений рассматривается в будущем выпуске.

Ivan Stoev 11.04.2018 14:00

@WiktorZychla: Хотя это технически возможно, чтобы иметь другие свойства в сущности (те, которые не отображаются в таблице БД), это просто не хороший подход для этого. Помимо прочего, это нарушает SRP. Стандарты кодирования, такие как SRP, не могут быть эмпирически подтверждены или опровергнуты; они руководство для хорошего развития. Запрос доказательств на самом деле не имеет отношения к руководствам.

Flater 11.04.2018 14:20

@Flatter: SRP не имеет ничего общего со свойствами, которые не отображаются в базе данных. Основная ответственность объекта заключается не в его отображении в базу данных, а в той роли, которую он играет в вашем домене. Если вы следуете DDD, у вас могут быть довольно богатые сущности, где только выбранная часть вашей сущности - это возможно, сохраняемое в базе данных. Спорным является то, что Сервисы раскрывается вашими объектами, это, возможно, нарушает SRP, однако вопрос не в DDD / SRP и принципах, а в техническом плане - как избежать сопоставления непримитивного свойства и при этом ввести его.

Wiktor Zychla 11.04.2018 14:57

Я верю в DDD и пытаюсь решить проблему использования и контроля DateTimes в домене. Я хочу, чтобы объект домена создавал внутренние объекты и записывал, когда они были созданы. Я хочу иметь возможность контролировать эти даты для целей модульного тестирования

chris31389 11.04.2018 16:31

Может это проблема дизайна.

chris31389 11.04.2018 16:32
0
9
63
1

Ответы 1

Если вы не хотите создавать столбец в базе данных, вы можете использовать аннотацию [NotMapped] для свойства. Больше информации:

http://www.entityframeworktutorial.net/code-first/notmapped-dataannotations-attribute-in-code-first.aspx

Как бы вы заполняли свойство DateTimeProvider, когда оно загружается из базы данных?

chris31389 11.04.2018 16:28

Разве вы не можете сделать это в конструкторе?

illug 11.04.2018 16:49

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

chris31389 11.04.2018 18:20

Другие вопросы по теме