Лучший способ поддерживать GUI в актуальном состоянии при изменении данных представления SQL?

Question

Допустим, у вас есть форма с компонентом, который отображает данные из представления на сервере SQL. Компонент может быть чем-то вроде ListView или DataGrid - в основном это то, что может отображать данные в формате 2D-сетки. Другое приложение изменяет данные, которые описывает представление SQL, и делает это регулярно, но с неопределенными интервалами.

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

Платформа ограничена тем, что вы должны использовать .NET 2.0 и Microsoft SQL Server. Предполагая, что вы имеете полный контроль над всеми остальными частями этой системы и можете спроектировать ее любым удобным для вас способом - как лучше всего это сделать?

Те, о которых я думал до сих пор:

• Регулярный опрос данных и сравнение, чтобы увидеть, что изменилось. Либо:

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

• Добавление слоя между SQL Server и формой и приложением обновлений, поэтому любые обновления из основного приложения идут сюда, и приложение формы может уведомляться об изменениях в режиме реального времени. Не совсем уверен, как это будет сделано на практике.

• Размещение в таблицах триггеров, которые каким-то образом вызывают уведомление формы - возможно, вызывая некоторые пользовательские расширенные хранимые процедуры?

Всем, кто делал это раньше, пожалуйста, предложите свои идеи!

Также, пожалуйста, прокомментируйте, если вам известны какие-либо существующие библиотеки, которые уже все это делают.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

SQL Server предусматривает уведомление клиентов об обновлениях определенной таблицы. В зависимости от объема обновлений это может быть подход. Я думаю, что это требует SQL 2005 или более поздней версии, но я не могу вспомнить наверняка.

Если у вас большой объем обновлений исходной таблицы, ваше второе предложение может сработать. Один из подходов заключается в использовании WCF и использовании механизма обратного вызова. Служба должна быть либо одноуровневой, либо сеансовой, но она будет отслеживать, какие клиенты к ней подключены, когда каждый клиент регистрирует обратный вызов при открытии прокси-сервера. Затем клиенты будут отправлять обновления через службу, а в качестве последнего действия в транзакции обновления для базы данных вы будете выполнять цикл обслуживания всех клиентов и уведомлять их об обновлении (я полагаю, что с обновленными данными данные, поэтому вы не запрашиваете базу данных). Это, конечно, будет означать дополнительную нагрузку на средний уровень, но это может определенно сработать.

Answer 4

Читайте о Query Notification. Если нет необходимости отслеживать слишком много запросов или клиентов, это может быть хорошим решением.