Entity framework - сохранение графика объектов POCO

Question

В моем приложении мне нужно получить большой граф объектов, внести различные изменения в то время как отсоединено (добавлять сущности, вносить изменения, удалять сущности), а затем сохранить график обратно в база данных. Я пробовал STE, но он начинает чрезмерно усложнять некоторые аспекты моего клиентского уровня, поэтому я надеялся сохранить все просто (по крайней мере, на стороне клиента), используя вместо этого POCOs.

Когда речь идет о сохраняющихся изменений, я думал, что я мог бы получить график из базы данных снова, и ходить как этот график и график от клиентского уровня, ищет различия: -

• удаление происходит, когда объект существует в графе базы данных, но не граф клиента. Предположительно, я могу просто .Remove() их из графика базы данных.
• Новые объекты - это те, что указаны в графике клиента с идентификатором 0. Предположительно, я могу только .Add() их использовать в графике базы данных.
• Я не уверен, что лучший способ справиться с обновлениями. Я не хочу реализовывать флаг IsDirty для своих объектов и предпочитаю более автоматическое решение. Итак, а) есть ли способ сравнить объект на графике клиента с его коллегой базы данных, чтобы узнать, изменился ли он, и б) каким образом можно применить или объединить клиентский объект в свою базу данных?

Как только все это сделано, я предположительно просто вызываю SaveChanges() на графике базы данных. Я также должен был бы передать этот график клиенту, чтобы он имел последнюю версию (значения, сгенерированные с помощью базы данных, такие как идентификаторы, временные метки).

Является ли мое решение слишком упрощенным? Если это возможно, как я могу справиться с обновлениями, как описано выше?

Answer 1

Ваше решение может работать, но реализовать его не просто - особенно если вы попытаетесь сделать это как-то общее (проверьте ответы в this question - кто-то предложил базу кода, которая должна иметь это уже реализовано). Это также вызывает много дополнительного трафика для базы данных, поэтому это определенно не очень хороший подход, когда вы ожидаете некоторой большой нагрузки. Самое простое решение - это то, что сказал @ Герт Арнольд.