Ограничить сериализацию всего графа объектов при вызове службы WCF для обновления объекта EntityObject - PullRequest
2 голосов
/ 01 апреля 2010

У нас есть служба WCF, которая использует Entity Framework для запроса базы данных SQL. Служба WCF - это наш уровень доступа к данным. Если какое-либо из наших приложений предназначено для чтения / записи данных в базу данных и из нее, мы вызываем метод службы WCF. Служба WCF сериализует объекты EntityObject для клиентских приложений.

В клиентском приложении (например, приложении WPF или приложении ASP.NET) мы можем обновить свойство объекта и вызвать службу WCF, передав объект в качестве параметра, для обновления базы данных. Обновленный объект может иметь сотни дочерних объектов, связанных с ним.

Например, у объекта Customer будет свойство Projects, представляющее собой список объектов Project. Если наше клиентское приложение изменяет простое скалярное свойство в объекте Customer, например CustomerName, нам нужно сохранить это изменение в базе данных, вызвав метод обновления в службе WCF. Проблема в том, что мы передаем сущность Customer в службу для обновления, но все присоединенные проекты также сериализуются и передаются в службу WCF, хотя метод обновления службы WCF касается только изменений скалярных свойств в Customer юридическое лицо. Очевидно, что мы сериализуем и передаем гораздо больше данных, чем необходимо.

Кто-нибудь имел опыт решения этой проблемы? Так или иначе, я хотел бы только сериализовать сущность Customer обратно в службу WCF, не выполняя глубокую сериализацию всего графа объектов.

Спасибо.

Ответы [ 4 ]

3 голосов
/ 13 июля 2010

Либо вы ограничиваете то, что хотите передать с помощью DataAnnotations, либо лучше было бы создать собственную модель для данных, которые вы хотите передать по проводной связи.здесь все намерения (сопоставление между базой данных, сопоставление между службой и клиентом) имеют свою собственную выделенную модель.

сопоставление между двумя моделями может быть очень легко выполнено с помощью autompper.

1 голос
/ 14 июля 2010

Вы можете использовать свойство maxItemsInObjectGraph объекта DataContractSerializer , чтобы ограничить сериализацию. Вы можете легко попробовать это, используя элемент конфигурации в конфигурации поведения. Например

<behaviors>
<behavior name="CustomerUpdate">
<dataContractSerializer maxItemsInObjectGraph="1" />
</behavior>
</behaviors>

Еще один вариант, который я могу придумать, - создать DataContract Surrogate , который удаляет информацию, которую вы не хотите сериализовать. Для этого следует создать класс, который реализует IDataContractSurrogate и использовать метод GetObjectToSerialize , чтобы изменить объект клиента, чтобы он не включал в себя ни одну из связанных коллекций объектов.

Этот подход действительно беспокоит меня по ряду причин

  • Это требует больших усилий, в конечном итоге вы можете построить поведение, упрощающее повторное использование, но это не исключает первоначальных усилий
  • Я не могу придумать общий способ решения этой проблемы для всех сущностей (если только вы не решите не отправлять всю коллекцию или перечисляемые свойства)

Так что я бы определенно попытался использовать maxItemsInObjectGraph first

НТН

1 голос
/ 01 июля 2010

Я использую hibernate (Java / grails) и пытаюсь реализовать Hessian, и у меня точно такая же проблема - кажется, что hessian пытается сериализовать весь граф объектов, но мне нужен только один объект. Вы сталкивались с решением? Документация гессиана не совсем точна, ошибочна, переполнена информацией или параметрами конфигурации.

0 голосов
/ 14 июля 2010

Ну, это не так просто найти решение этой проблемы ... на самом деле вам нужно отслеживать изменения в ваших сущностях и помечать их как грязные соответственно, а затем применять операции CURD / только к тем сущностям в графе объектов, у которых есть грязные флаг установлен.

Вот похожее обсуждение: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/89b7087a-1b08-4fe0-9cc3-68986fe89a74

С уважением.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...