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

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

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

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

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

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

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

2) Использовать шаблон прокси Flyweight +.

In general I think the answer to your question is that there isn't one or more Design Patterns that will really solve your problem. Instead, this is a great example of a decently large-scale application which just needs a lot of planning and design work.

When you're designing, I think you'll come across some DPs that may help you on a small level, but the details of how this giant thing should work is more of a general (and interesting) design problem.

Perhaps clarifying your questions slightly may help lead people to giving advice on the overall design for this system. Also, once you've put some design/effort into coming up with a high-level design of how this should work, you could ask for critiques/suggestions. It's hard for someone to come up with this completely as an answer to a StackOverflow question. :)

I think you might be missing something: since Silverlight 3 there's the ability to push data to the client. Here's an article which might be helpful with that.

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

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

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

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

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

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

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

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

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

■ Нет необходимости обновлять состояние клиента немедленно, клиент может предпочесть, чтобы изменения накапливались, а не получали каждое обновление, поэтому опрос будет предпочтительнее.

s Нет необходимости обновлять состояние клиента немедленно, клиент может предпочесть, чтобы изменения накапливались, а не получали каждое обновление, поэтому опрос будет предпочтительнее.

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

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