У меня есть очень простая операция EF, которая не: разорвать отношения между двумя субъектами, как показано в коде ниже:отношений не установлен в нуль
public async Task RemoveCurrentTeacherOfGroup(int groupId)
{
var group = await _dataContext.Groups.SingleAsync(g => g.Id == groupId);
group.Teacher = null;
await _dataContext.SaveChangesAsync();
}
База данных генерируется код-первых. Объекты определяются следующим образом:
public class Teacher
{
public int Id { get; set; }
..
public virtual List<Group> Groups { get; set; }
}
public class Group
{
public int Id { get; set; }
..
public virtual Teacher Teacher { get; set; }
}
Однако, нарушая связи не работает, Учитель продолжает указывать на тот же объект. При переходе с отладчиком я вижу, что свойство Teacher не становится null после .Teacher = null. Я попробовал его с синхронной альтернативой, которая имела такой же эффект:
public void RemoveCurrentTeacherOfGroup(int groupId)
{
var group = _dataContext.Groups.Single(g => g.Id == groupId);
group.Teacher = null;
_dataContext.SaveChanges();
}
Спасибо! Off Topic: Я думаю, что это недостаток в EF. Объект прокси-сервера может обнаруживать, что в его сеттере установлено значение null; внешний ключ известен (используется для ленивой загрузки), поэтому EF может удалить его и установить свойство в измененное состояние. – mnwsmit
@mnwsmit Я предполагаю, что это по соображениям производительности: если вы собираетесь просто «установить связанный объект», нет необходимости округлять до базы данных, чтобы увидеть, «было ли оно« null », потому что оно не было загружено, или оно было нулевым, потому что оно был фактически нулевым ». Все, что обращается к базе данных, должно быть тщательно выполнено (и установка связанного объекта не обязательно обязательно нуждается) – Jcl
Однако эта информация уже известна: внутри прокси-объекта хранится внешний ключ. Таким образом, EF уже знает, что отношение является только нулевым из-за ленивой загрузки. – mnwsmit