Я работаю над распределенным приложением с сервером и клиентом, где сервер предоставляет сервисы через WCF.Сервер использует Entity Framework, и его различные методы возвращают EntityObjects.
В клиенте у меня нет ссылок на сервер.Таким образом, в клиенте классы являются полностью сгенерированными прокси.
У меня есть метод удаления на сервере.Когда я передаю объект (обратно) для удаления, он делает это (без обработки исключений и т. Д.):
public void DeleteCarrier(CarrierDefinition carrier)
{
var container = new WsaEntities();
if (carrier.EntityState == EntityState.Detached)
{
container.CarrierDefinitions.Attach(carrier);
}
container.CarrierDefinitions.DeleteObject(carrier);
container.SaveChanges();
}
Две другие таблицы имеют внешние ключи для CarrierDefinition.Один из FKs обнуляется с ограничением ON CASCADE SET NULL, другой имеет CASCADE DELETE.Приведенный выше код выдает мне исключение:
Операция не выполнена: связь не может быть изменена, так как одно или несколько свойств внешнего ключа не могут иметь значение NULL.Когда в отношение вносится изменение, для соответствующего свойства внешнего ключа устанавливается нулевое значение.Если внешний ключ не поддерживает нулевые значения, необходимо определить новое отношение, свойству внешнего ключа должно быть назначено другое ненулевое значение или несвязанный объект должен быть удален.
Однако, если я удаляю сущность, которая не была подвергнута циклическому отключению таким образом, она работает как ожидалось:
public void DeleteCarrier(Guid carrierId)
{
var container = new WsaEntities();
var c = container.CarrierDefinitions.Where(cd => cd.Id == carrierId).First();
container.CarrierDefinitions.DeleteObject(c);
container.SaveChanges();
}
Здесь ON CASCADE SET NULL и ON CASCADE DELETE работают просто отлично.
Я проверил аргумент оператора (сущности) в режиме отладки и не смог найти ничего плохого.В частности, коллекции сущностей заполняются и содержат связанные объекты.Он выглядит удивительно полным и правильным, учитывая, что он был сериализован, затем десериализован в прокси-класс и наоборот.Но где-то, что-то просто не совсем верно.
Я знаю, что с таким же успехом могу использовать сигнатуру этого метода и двигаться дальше, или даже сохранить сигнатуру и использовать свойство Id аргумента носителя вместо аргумента carrierId,Но я беспокоюсь, что это будет первой из многих проблем, потому что что-то не так с этим подходом.
Что я могу попробовать?Есть ли что-то, что я должен сделать, кроме прикрепления объекта, например?
Я должен упомянуть, что я использую SQL Server Compact Edition v3.5, хотя мне кажется, что это не проблемав данном конкретном случае.