Самостоятельная оптимизация трафика

Question

Я работаю над личным проектом, использующим WPF с Entity Framework и Self Tracking Entities.У меня есть веб-сервис WCF, который предоставляет некоторые методы для операций CRUD.Сегодня я решил сделать несколько тестов и посмотреть, что на самом деле путешествует по этому сервису, и хотя я ожидал чего-то подобного, я был очень разочарован.Проблема заключается в том, что для простой операции обновления (или удаления) только для одного объекта - скажем, Category , я отправляю на сервер весь граф объектов, включая все его родительские категории, их элементы, дочерние категории иих элементы и т. д. В моем случае это был XML-файл размером 170 КБ в очень маленькой базе данных (2 основные категории, всего около 20 и около 60 элементов).Я не представляю, что произойдет, если у меня действительно большая база данных.

Я попытался найти в Google несколько статей, касающихся оптимизации трафика с помощью STE, но безуспешно, поэтому я решил спросить здесь, сделал ли кто-точто-то похожее, знакомы с некоторыми хорошими практиками и т. д.

Один из возможных способов, с помощью которых я пришел, состоит в том, чтобы получить нужные мне данные для объекта с большим количеством вызовов службы:

return context.Categories.ToList();//only the categories
...
return context.Items.ToList();//only the items

Вместо:

return context.Categories.Include("Items").ToList();

Таким образом, категории и элементы будут разделены, и при внесении изменений или удалении некоторых объектов данные, передаваемые по проводам, будут меньше.

Кто-нибудь из вас сталкивался спохожая проблема и как вы ее решили или решили?

Answer 1

Элемент проекта Entity Framework можно найти по адресу http://selftrackingentity.codeplex.com/.. В версии 0.9.8 я добавил метод с именем GetObjectGraphChanges(), который возвращает оптимизированный граф объектов-сущностей только с объектами, которые имеют изменения.1005 * Также есть два вспомогательных метода: EstimateObjectGraphSize() и EstimateObjectGraphChangeSize().Первый метод возвращает оценочный размер всего объекта сущности вместе с его графом объекта;и последний возвращает оценочный размер оптимизированного графа объекта сущности с единственным объектом, у которого есть изменения.С помощью этих двух вспомогательных методов вы можете решить, имеет ли смысл вызывать GetObjectGraphChanges() или нет.

Answer 2

Мы столкнулись с похожими проблемами. Прежде всего, как вы уже упомянули, необходимо поддерживать как можно меньшие размеры сущностей (в зависимости от требуемой функциональности клиента). И, во-вторых, при отправке сущностей обратно по проводам для сохранения: удалите все свойства навигации (вложенные объекты), когда они не изменились. Это звучит очень просто, но совсем не тривиально. Что мы делаем, это рекурсивно копаем сущности, присутствующие в отслеживаемых коллекциях, скажем, «самой верхней» сущности (и их отслеживаемые коллекции, и их, и ...), и удаляем их, когда их состояние ChangeTracking равно «Не изменено». Но будьте осторожны с этим, потому что в некоторых случаях вам все еще нужны эти сущности, потому что они были удалены или добавлены в отслеживаемые коллекции их родительской сущности (поэтому вы не должны их удалять).

Это то, что мы называем "StripEntity", также упоминается (не с каким-либо примером кода или чем-либо еще) в Julie Lerman's - Programming Entity Framework .

И хотя это может быть не так эффективно, как более пуристский подход, использование STE экономит много кода для запросов к базе данных. Мы не нуждаемся в оптимальной производительности в условиях интенсивного трафика, поэтому STE отвечает нашим потребностям и отнимает много кода для связи с базой данных. Вы должны решить для своей ситуации, каково «лучшее» решение. Удачи!