Как правильно редактировать сущности EF с null

@angelodemon2017 · Регистрация: 09.10.2017

Студворк — интернет-сервис помощи студентам

Добрый день, господа.
Ситуация такая, используется EF6, есть метод редактирования сущности и сохранения её в БД:

C#
1
2
3
4
5
6
7
8
9
10
public void EditUser(SUser editUser)
{
 using(var dbCon = new DBContext())
 {
  var searchingUser = dbCon.Find(editUser.Id);
  editUser.prop1 != null ? searchingUser.prop1 = editUser.prop1 : null;
  ...
  dbCon.SaveChanges();
 }
}

у модели User допустим 1000 полей, дабы не плодить методы, требуется написать один, в котором будет правка всех полей. Данный пример работает корректно, если предварительно мы загрузили редактируемую модель полностью.
Но если нам было необходимо поправить только 1 поле из 1000, и предварительно из базы мы взяли сущность с Id и полем, которое надо изменить, а может быть случай, если нам такая правка нужна сразу у 2000 сущностей => зачем загружать все данные, когда изменить надо только одно поле в каждой сущности? В итоге в приведенный метод прилетает модель только с 2 известными свойствами, а все остальные равны null или значениям по умолчанию, тогда этот метод перезапишет поля не верно.

Т.е. как правильно оформить случай, когда свойство = null, потому что null надо записать в БД, и другой null, когда поле в бд нужно пропустить?

@Usaga · 31.10.2019, 08:55

Сообщение от angelodemon2017

у модели User допустим 1000 полей

Это значит, что у вас очень кривая схема базы. Наверняка такая таблица склеена из нескольких (т.е. лечится разбиением таблицы и соответствующих сущностей).

Сообщение от angelodemon2017

Данный пример работает корректно, если предварительно мы загрузили редактируемую модель полностью.

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

Есть, конечно, обходной путь. Можно создать пустую сущность, напихать в неё значения полей, что нужно обновить (включая ID по которому запись в базе будет обновляться). А потом в ChangeTracker'е тыка EF'у какие свойства изменились. Но это настолько костыльно, что лучше сделать вид, что я этого не говорил.

Сообщение от angelodemon2017

Т.е. как правильно оформить случай, когда свойство = null, потому что null надо записать в БД, и другой null, когда поле в бд нужно пропустить?

Очень просто: на каждый сценарий обновления - свой класс с перечнем свойств, что нужно у сущности обновить. Тогда разночтения с null'ами не будет. Если свойство есть, значит его надо обновить, даже если в нём null. Нет свойства в DTO'шке? Значит соответствующее в сущности обновлять не надо.

Пример:

C#
1
2
3
4
5
6
7
8
9
10
class UpdateUserNameRequest
{
    public string Name { get; set; }
}
 
class UpdateUserEmailAndNickRequest
{
    public string EMail { get; set; }
    public string Nick { get; set; }
}

Передавая в метод обновления класс UpdateUserNameRequest вы чётко и ясно говорите коду, что хотите обновить только имя пользователя. Мэйла и ника в этой DTO нет, значит и в сущности их трогать не надо.

Т.е. на каждый сценарий обновления у вас будет свой метод принимающий свою DTO. Но во всех методах вам придётся выгружать всю сущность целиком. Без вариантов.

EF очень деревянный ORM. Он старается скрыть от вас факт того, что вы работаете с СУБД и представить, что работа идёт с объектами в памяти. Оттуда и такие ограничения.

Если для вас это критично, то рассмотрите вариант использования Linq2Db. Оно и поля отдельные апдейтить умеет и на ушах стоять и всё остальное.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

Опции темы

Как правильно редактировать сущности EF с null

Решение