Привет!

С .NET работаю с самой первой beta версии. В IT еще дольше.
Разбираюсь use case-ами применения records и как не стараюсь, не могу найти.
Именно на практике, а не в теории.

Поделитесь пожалуйста, кто их практически применяет — где, для чего?

Спасибо заранее!

Здравствуйте, Yuri Abele, Вы писали:

YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?
YA>Спасибо заранее!

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

Здравствуйте, Yuri Abele, Вы писали:
YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?
При выходе 5-ки в одном проекте завел 3 записи типа, руками их не создаю, только путем десериализации получаю экземпляры, плюс в компактности

        public record SendResponse([property: JsonPropertyName("status")] string Status,
            [property: JsonPropertyName("status_code")] int StatusCode,
            [property: JsonPropertyName("status_text")] int StatusText,
            [property: JsonPropertyName("balance")] decimal Balance,
            [property: JsonPropertyName("sms")] IDictionary<string, ShortMessageSendResult> Results);

А вот для работы с той же EF уже не катит. да специфично.
сам поражаюсь ненужности.

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, Yuri Abele, Вы писали:
YA>>Поделитесь пожалуйста, кто их практически применяет — где, для чего?
vaa>При выходе 5-ки в одном проекте завел 3 записи типа, руками их не создаю, только путем десериализации получаю экземпляры, плюс в компактности
vaa>

vaa>        public record SendResponse([property: JsonPropertyName("status")] string Status,
vaa>            [property: JsonPropertyName("status_code")] int StatusCode,
vaa>            [property: JsonPropertyName("status_text")] int StatusText,
vaa>            [property: JsonPropertyName("balance")] decimal Balance,
vaa>            [property: JsonPropertyName("sms")] IDictionary<string, ShortMessageSendResult> Results);
vaa>

vaa>А вот для работы с той же EF уже не катит. да специфично.
vaa>сам поражаюсь ненужности.
Для ViewModels пожалуй да — они, по факту, только один раз создаются.
НО! Но для преобразования из Model во ViewModel (необходимо для подготовки Response), с использованием авто маппинга (например AutoMapper), необходим default конструктор без параметров — а это не records (если я правильно разобрался).

P.S. для NewtonJson можно сконфигурировать такое преобразование имён (snake_case <==> PascalCase) автоматически.

Здравствуйте, Yuri Abele, Вы писали:

YA>Привет!

YA>С .NET работаю с самой первой beta версии. В IT еще дольше.
YA>Разбираюсь use case-ами применения records и как не стараюсь, не могу найти.
YA>Именно на практике, а не в теории.

YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?

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

То есть, для DTO и DBO.

Здравствуйте, Yuri Abele, Вы писали:

YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?

Удобно делать record для Id. Т.е. не

class User { public int Id { get; } ... } 
class Product { public int Id { get; } ... }

а

class User { public UserId Id { get; } ... } 
class Product { public ProductId Id { get; } ... }

Соответственно (утрированно) user.Id = product.Id уже не пройдет.
Более того, такой Id может быть составным и содержать несколько свойств (которые в итоге замапятся на композитный ключ в БД).

Здравствуйте, Yuri Abele, Вы писали:

YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?

В чистой архитектуре в DDD Value Objects можно представить как records , т.к. Value Objects должны быть имутабельны и не иметь идентификации, а если Value Objects сравниваются, то должны сравниваться сразу по всем полям.

Здравствуйте, Doc, Вы писали:


Doc>

Doc>class User { public UserId Id { get; } ... } 
Doc>class Product { public ProductId Id { get; } ... }
Doc>

и как это нормально работает с EF?
без дополнительных настроек? и select и saveChange?

Здравствуйте, vaa, Вы писали:

vaa>и как это нормально работает с EF?

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

В сети читал что делают, когда хочется сразу сохранять такие классы в EF — создают Value Conversions, который автоматом мапит такие record на таблицу.
https://thomaslevesque.com/2020/12/23/csharp-9-records-as-strongly-typed-ids-part-4-entity-framework-core-integration/

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, vaa, Вы писали:

vaa>>и как это нормально работает с EF?

Doc>Мы не сохраняем модели напрямую, есть маппинг на entities которые представляют уже собой талицы БД или другие хранилища (и они не обязательно 1 в 1 с моделями).
Doc>У нас все ок, но конечно это не ответ на исходный вопрос

понятно, но все же не очень удобно использовать записи, если нужно извлечь из бд, изменить и сохранить. т.е. придется писать with и context.Entity().State = Attach.
вообщем огород нехилый. в таких случаях конечно ОРМ становится препятствием.

Здравствуйте, vaa, Вы писали:

vaa>понятно, но все же не очень удобно использовать записи, если нужно извлечь из бд, изменить и сохранить. т.е. придется писать with и context.Entity().State = Attach.

Зачем? Может что-то упустил, но чем Value Conversions не подходят?

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, vaa, Вы писали:

vaa>>понятно, но все же не очень удобно использовать записи, если нужно извлечь из бд, изменить и сохранить. т.е. придется писать with и context.Entity().State = Attach.

Doc>Зачем? Может что-то упустил, но чем Value Conversions не подходят?
Value Conversions работают норм? Писали, что какие-то сложности возникают в linq to sql.
record по умолчанию иммутабельный же, а кастомить его это как обычный класс почти описать. мое субъективное, пока опыта нет.

Здравствуйте, Doc, Вы писали:

Doc>Зачем? Может что-то упустил, но чем Value Conversions не подходят?
Допустим имеем сущности:

public record ItemId(int Id);
public record Item (ItemId Id, string Name);

Как добавить новую запись в ОРМ типа ef core?
record требует что-то типа:

 new(new ItemId(???), "Alice")

Не ясно как обойти это ограничение, как получить автогенерацию для ключа.
Если есть где-то примеры, был бы рад изучить.

Здравствуйте, Doc, Вы писали:

Doc>Зачем? Может что-то упустил, но чем Value Conversions не подходят?
https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/types/records
если я правильно перевел, записи вообще не подходят для ОРМ EF

Value equality
For records, value equality means that two variables of a record type are equal if the types match and all property and field values match. For other reference types such as classes, equality means reference equality. That is, two variables of a class type are equal if they refer to the same object. Methods and operators that determine equality of two record instances use value equality.

Not all data models work well with value equality. For example, Entity Framework Core depends on reference equality to ensure that it uses only one instance of an entity type for what is conceptually one entity. For this reason, record types aren't appropriate for use as entity types in Entity Framework Core.

Immutability
An immutable type is one that prevents you from changing any property or field values of an object after it's instantiated. Immutability can be useful when you need a type to be thread-safe or you're depending on a hash code remaining the same in a hash table. Records provide concise syntax for creating and working with immutable types.

Immutability isn't appropriate for all data scenarios. Entity Framework Core, for example, doesn't support updating with immutable entity types.

Здравствуйте, Yuri Abele, Вы писали:

YA>Привет!

YA>С .NET работаю с самой первой beta версии. В IT еще дольше.
YA>Разбираюсь use case-ами применения records и как не стараюсь, не могу найти.
YA>Именно на практике, а не в теории.

YA>Поделитесь пожалуйста, кто их практически применяет — где, для чего?

YA>Спасибо заранее!

Вот тоже не понимаю. Ждал чего-то подобного как удобный способ инициализации объектов (т.е. возможность объявить все зависимости DI один раз в конструкторе), а в итоге получилось что-то совсем непонятное в плане удобства.

Здравствуйте, vaa, Вы писали:

Doc>>Зачем? Может что-то упустил, но чем Value Conversions не подходят?
vaa>Value Conversions работают норм? Писали, что какие-то сложности возникают в linq to sql.

Использовали не часто, но проблем у нас не было.

Здравствуйте, vaa, Вы писали:

vaa>если я правильно перевел, записи вообще не подходят для ОРМ EF

Тут речь про record как entity, а я выше говорил про случае когда entity это class, который содержит record (например Id).

Здравствуйте, Somescout, Вы писали:

S>Вот тоже не понимаю. Ждал чего-то подобного как удобный способ инициализации объектов (т.е. возможность объявить все зависимости DI один раз в конструкторе), а в итоге получилось что-то совсем непонятное в плане удобства.

Рекорды с DI зависимостями. Вот это точно что то очень странное.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Рекорды с DI зависимостями. Вот это точно что то очень странное.

Не записи, просто способ объявления полей класса в конструкторе, чтобы вместо:

class Test {
  private readonly DBContext dbContext;
  private readonly ADContext adContext;

  public Test(DBContext dbContext, ADContext adContext) {
    this.dbContext = dbContext;
    this.adContext = adContext;
  }
}

Который абсолютно шаблонен, написать просто:

class Test {
  public Test(
    private readonly DBContext dbContext,
    private readonly ADContext adContext
  ) { }
}

Мелкая экономия в принципе, но устраняет постоянно повторяющийся код.

Здравствуйте, Somescout, Вы писали:

S>Не записи, просто способ объявления полей класса в конструкторе, чтобы вместо:

Рекорды предназначены для сценария DTO. Делать DTO с DI зависимостями — очень нестандартная идея.