Кэширование данных и уведомление клиентов об изменениях данных в ASP.NET

Question

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

Изменение, которое я имею в виду в этом посте, как это:

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

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

мне нужен ваш просвещенный совет здесь ребята:

1) Is it a good idea to keep a local cache on the clients to begin with? 
2) If we do decide to keep a local cache on the clients, would you use 
    SqlCacheDependency to notify the clients, or would you use WCF for 
    notifications (each might have its cons and pros) 

Спасибо большие, ребята,

Avi

Answer 1

Мне нравится звук вашего SqlCacheDependency, но я ответить на этот вопрос с другой точки зрения поскольку я работал с командой по аналогичному сценарию. Мы создали основную базу данных и использовали триггеры для создания XML-представлений данных, которые были изменены в главном, и сохранили их в таблице TransactionQueue с небольшим количеством метаданных о том, что изменилось, когда и кто изменил его. Клиентские базы данных периодически проверяли очередь на интересующие элементы и обрабатывали XML и обновляли свои собственные таблицы по мере необходимости.

Мы также сделали то же самое в обратном для клиента, чтобы обновить мастер. Мы настраиваем триггеры и таблицу TransactionQueue в клиентских базах данных для отправки данных обратно в мастер. Это, в свою очередь, будет обновлять все остальные клиентские базы данных, когда они будут в следующем опросе.

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

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

Удачи вам! Tim