Есть ли шаблон проектирования для работы с большими наборами данных через Интернет?

шаблон проектирования прокси - это шаблон, который поможет в передаче данных из одной точки в другую. . Шаблон проектирования прокси позволит вам обрабатывать удаленные объекты, как если бы они были локальными.

2 предложенных решения могут быть

1) сожмите вашу коллекцию и распакуйте ее после передачи.

2) Используйте шаблон «Легковес + прокси».

Интересно, можно ли вообще уменьшить объем данных, поступающих на экран клиента? В любом случае вы не можете увидеть сразу 5 000 точек данных. И если вам нужно прокрутить для поиска важных вещей, подумайте о том, чтобы для начала отфильтровать неважные. Рассмотрим некоторые варианты дизайна пользовательского интерфейса (приборная панель и элементы типа датчика), чтобы пользователь видел только проблемные места. Затем они могут углубиться в детали и предпринять необходимые действия.

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

Здесь я нашел статью, которая, кажется, объясняет, как создавать сокеты в Silverlight 2 Silverlight 2 и System.Net.Sockets.Socket

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

Здесь руководство по каналу 9 Silverlight с использованием сокета

Я надеюсь, это поможет

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

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

Возможно, небольшое уточнение ваших вопросов может помочь людям дать совет по общему дизайну этой системы. Кроме того, как только вы приложили определенные усилия / дизайн для создания высокоуровневого проекта того, как это должно работать, вы можете попросить критику / предложения. Трудно придумать это полностью как ответ на вопрос StackOverflow. :)

Если я правильно понял, здесь действительно две проблемы:

1. Состояние системы представлено данными, поступающими из нескольких источников данных. В результате запрос состояния обходится дорого.
2. Объем данных, описывающих состояние системы, велик. В результате запрашивать все данные, описывающие состояние, дорого.

Стандартные шаблоны для решения этих проблем заключаются в том, чтобы ввести средний уровень и использовать дельты для обновления состояния. Например.:

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

2. Предполагая, что каждая запись будет иметь идентификатор, клиент должен запрашивать только дельты с момента последнего обновления. Один из многих шаблонов - использовать временную метку. Например. при инициализации клиент запрашивает состояние системы, а средний уровень отправляет это состояние с отметкой времени. Когда клиенту необходимо обновить определенные записи, он предоставляет идентификаторы в запросе и отметку времени последнего обновления. Поэтому средний уровень будет отправлять только изменения с последней отметки времени и только для запрошенных идентификаторов. Если объект имеет 15 свойств, и только 3 из них были изменены с момента последней отметки времени, то обновление будет содержать только значения этих 3 свойств.

Что касается push vs. poll - push автоматически не является лучшим решением. На самом деле все сводится к вопросу о компромиссе между частотой обновления клиента и объемом трафика между клиентом / средним уровнем. Например. если изменение состояния происходит часто, но редко (например, влияет только на несколько свойств за раз) и нет необходимости немедленно обновлять состояние клиента, клиент может предпочесть, чтобы изменения накапливались, а не получали каждое обновление, поэтому опрос будет предпочтительнее.

Я думаю, вам может чего-то не хватать: начиная с Silverlight 3 появилась возможность отправлять данные клиенту. Здесь статья, которая может быть вам полезна.

Я проголосовал за пару хороших ответов, но нашел решение с некоторыми изменениями в серверных данных и новым способом получения данных из Silverlight. Вот что делается для решения этой проблемы:

1. Я использую beans для представления этого большого графа данных. Это удалило много передачи XML. В любом случае меня интересует только часть данных, хотя это довольно значительная часть. Сглаживая данные в bean-компонент, я думаю, что сократил размер сериализованного объекта примерно до 20-25% от исходного графа объекта.
2. Почти все данные на бэкенде теперь будут иметь поле, когда оно было изменено в последний раз. Я смог получить это для всех больших данных. Есть несколько фрагментов данных, в которых этого не будет, но с его помощью были решены реальные проблемы с производительностью запросов и агрегацией данных. В качестве общего решения для других, похоже, это довольно просто реализовать в ряде СУБД.
3. Я пишу новые API для получения данных, которые были обновлены после указанного DateTime. Это позволяет мне запрашивать только новые и измененные объекты из серверной системы (это веб-служба, вызывающая эти API, а Silverlight вызывает веб-службу).
4. Обобщите изменения в веб-службе и определите, изменилась ли часть дейтаграфа. Для простоты я просто отправляю весь датаграф, если что-то изменилось. На самом деле это было сложнее всего понять. У части датаграфа могло быть новое обновленное время, но основной объект графика не был обновлен. В итоге мне пришлось написать API-интерфейсы для поиска изменений подобъектов, а затем API-интерфейсы для поиска корневых объектов на основе этих подобъектов (если они были изменены). Граф объектов может быть возвращен с корневым объектом (и фактически большей частью графа объекта), который не обновлялся с момента последнего опроса. Логика веб-службы запрашивает небольшое количество изменений, поэтому, хотя запросы не из дешевых по отдельности, они потенциально могут выполняться только несколько раз за опрос. Даже в очень больших установках нашего продукта этот цикл запроса будет выполняться только 10 или 20 раз за цикл опроса (см. О моем решении для опроса ниже). Хотя наши системы очень динамичны, не так меняется за 30 секунд. Вызов веб-службы, который обрабатывает все это, реагирует на вызов начальной загрузки так же, как и на опрос. Все, что его интересует, - это получение данных более свежих, чем заданное время.
5. Я написал коллекцию, унаследованную от ObservableCollection, которая обрабатывает запросы и опросы. Клиентский код, использующий эту коллекцию, предоставляет делегата, который запрашивает данные. Дата возвращается асинхронно и в страницах. Я еще не остановился на размере страницы. Он продолжает запрашивать страницы до тех пор, пока сервер не вернет страницу, размер которой меньше максимального размера страницы. В коллекции также предоставляется информация о том, как определить последнюю дату самого нового объекта в коллекции. Он периодически опрашивает обновления, которые новее, чем самый новый элемент в коллекции. На самом деле эта «последняя дата» на самом деле является объектом, содержащим несколько дат различных частей исходного графа объектов. Если элемент возвращается с сервера, который существует в коллекции, элемент в коллекции обновляется с помощью этих возвращенных данных. Я сделал это вместо того, чтобы вставить новый элемент и удалить старый, потому что он работает в большем количестве ситуаций с привязкой к данным.

Этот шаблон можно улучшить. Я мог отправлять в Silverlight только дельты для изменений. Я все еще мог бы попытаться использовать какую-то технологию push. Но это решение дает мне один вызов веб-службы, который может возвращать данные для различных случаев. Опрос также очень прост, и извлечение данных выполняет только одна вещь. Движущихся частей не так много. Это обрабатывает изменения состояния объекта как во время начальной загрузки данных, так и во время опроса с помощью одного и того же механизма. Это тоже хорошо масштабируется. Первоначальный вызов кажется самым дорогостоящим, а последующие вызовы выполняются все быстрее и быстрее. Я бы предположил, что это связано с тем, что данные, оставшиеся на сервере, становятся все меньше и меньше с каждым проходом.

У меня все еще есть один вопрос о моей реализации этого, что Я разместил здесь.

Спасибо за все предложения. Хотя я не прислушивался ко всем советам, несколько идей либо напрямую помогли мне, либо заставили меня задуматься о другом пути, как заставить это работать.