Графики объектов Entity Framework 4 + Silverlight

Question

В настоящее время мы создаем наше первое большое приложение с Silverlight 4 (используя PRISM) и Entity Framework 4. Теперь у меня возникает общий вопрос о сохраняющихся данных модели представления. Предположим, у меня есть объекты домена, которые переводят на объекты EF4 с несколькими ассоциациями (Entity имеет коллекции, имеющие коллекции снова и т. Д.). Каким будет лучший способ сохранить эти графики во время/после действий пользователя? Было бы лучше написать более гранулированные методы репозитория, такие как «AddEntityToParent» и «RemoveEntityFromParent», или просто взять все данные из представления и направить его на метод «SaveLargeParentEntity»? Могу ли я «кэшировать» элементы модели просмотра для дочерних объектов в Silverlight и в дальнейшем переместить все это на EF4, или мне нужно будет сделать подробное обновление для каждого элемента, измененного в пользовательском интерфейсе? Любой хороший совет? Надеюсь, мой вопрос был достаточно ясным. Спасибо.

Answer 1

Вы фактически делаете выбор между основными операциями CRUD и работой с графами объектов. Я бы выбрал второй подход, потому что CRUD operations over web service can be very chatty.

При работе с графами объектов, отправляемых через веб-службу, вы должны иметь дело с автономным поведением. Отдельные объекты + граф объектов couses some troubles при обновлении отношений. Наилучший подход обычно заключается в том, чтобы загрузить весь график перед обновлением (получить прикрепленные объекты) и слить полученный граф в прикрепленный файл - он будет правильно отслеживать изменения для вас.

Но поскольку вы используете Silverlight, который является состоятельным, вы также можете подумать об использовании объектов самообследования (STE). STE могут отслеживать изменения после их отсоединения от EF ObjectContext. Таким образом, вы можете вернуть граф объектов из STE из веб-службы в приложение Silverlight, внести некоторые изменения в STE и отправить один и тот же граф объектов обратно в веб-службу. Applying changes от STE будут обрабатывать много работы для вас. Имейте в виду, что STEs are not the best solution для служб, которые должны быть доступны для общих веб-приложений или не .NET-клиентов.