Сначала EF код - IsConcurrencyToken()

#c# #entity-framework #ef-code-first

#c# #entity-framework #сначала ef-код

Вопрос:

Простой, но все же загадочный для меня: почему для классов StringPropertyConfiguration (и всех других свойств) есть 2 перегрузки IsConcurrencyToken() ?

Первый:

public StringPropertyConfiguration IsConcurrencyToken()

Настраивает свойство для использования в качестве маркера оптимистичного параллелизма.

И второй:

public StringPropertyConfiguration IsConcurrencyToken(bool?)

Определяет, должно ли свойство использоваться в качестве токена оптимистичного параллелизма.

Зачем вам использовать одно поверх другого? На мой взгляд, между этими двумя перегрузками вообще нет разницы (по крайней мере, при работе с ними)…

Используя первый, вы могли бы написать что-то вроде:

 modelBuilder.Entity<Author>()
    .Property(x => x.Name)
    .IsConcurrencyToken();

И, используя второй, вы бы написали:

 modelBuilder.Entity<Author>()
    .Property(x => x.Name)
    .IsConcurrencyToken(true/false/null);

Я что-то пропустил?

Ответ №1:

Мое мнение…

IsConcurrencyToken() Значение по умолчанию равно true, чтобы обеспечить простой и плавный способ определения сущности.

IsConcurrencyToken(bool?) Позволяет автору окончательно установить ConcurrencyMode сущность. Это полезно для сложных сценариев:

Переопределение [ConcurrencyCheck] атрибута в POCO
Разрешение соглашения (удалено в EF 4.1 RTW) для включения / отключения ConcurrencyMode на основе некоторого пользовательского соглашения

Наконец, я думаю, что IsConcurrencyToken(false) это лучше, чем IsNotConcurrencyToken() .

1. 1 для «IsConcurrencyToken(false) лучше, чем IsNotConcurrencyToken()». Это то же самое, но слишком быстрое чтение второго может заставить кого-то подумать, что свойство ЯВЛЯЕТСЯ concurrencyToken (можно просто «пропустить» «НЕ» при быстром чтении).