Обновление источника данных с привязкой к данным в c # при изменении данных в базе данных - PullRequest
1 голос
/ 19 ноября 2009

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

Я запускаю приложение WPF с C # в качестве кода. База данных, которую я использую - SQL Server 2005.

Теперь я в настоящее время связываюсь с базой данных, используя ADO.Net и извлекаю данные из хранимых процедур в БД. Затем он сохраняется в наборах данных и далее по линии, связанной с элементами управления в моем приложении WPF.

Теперь данные, к которым я привязываюсь в БД, постоянно меняются, скажем, каждые несколько секунд. То, что я хочу, - это механизм, который автоматически сообщает мне в C #, когда изменились данные, к которым я привязан в БД, поэтому данные, возвращаемые из моих сохраненных процедур, изменились.

Я посмотрел в Интернете и обнаружил службы уведомлений и класс SQLDependency, но это устарело. Я также видел CLINQ, но, похоже, он не обрабатывает уведомление базы данных, он работает только для коллекций в c # из того, что я понимаю.

Я имею в виду, что метод плана B состоит в том, чтобы в моем коде C # имелась нить для опроса одного и того же хранимого процесса каждые несколько секунд на основе метки времени, которая хранится в каждой строке в возвращенном наборе данных. Если моя текущая временная метка больше, чем возвращаемая, восстановите эти данные. Затем он будет работать в этом новом потоке, повторяя цикл снова и снова. Если из соединения в потоке были возвращены какие-либо данные, это означало бы, что данные изменились, и поэтому сохраните эти данные в моих коллекциях на c #, чтобы их можно было связать с моим приложением WPF.

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

У кого-нибудь есть идеи по этому поводу?

высоко ценится Сомнительный.

Ответы [ 2 ]

0 голосов
/ 19 ноября 2009

План B звучит для меня как хороший выбор - в SQL Server нет встроенных способов уведомления, позволяющих вам сделать это, поэтому единственными вариантами будут:

  1. Триггеры в сочетании с пользовательскими функциями CLR. Проблема в том, что в зависимости от того, сколько работы вы выполняете в своей пользовательской функции, это может добавить довольно много накладных расходов для любого, кто пишет в базу данных - это не самый эффективный уровень для реализации механизма уведомлений.
    • Внедрите какой-то механизм уведомлений и убедитесь, что все, кто пишет в базу данных, используют этот механизм уведомлений, чтобы уведомить других об изменении данных.

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

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

0 голосов
/ 19 ноября 2009

как насчет триггеров SQL CLR? Триггеры SQL можно запускать каждый раз, когда происходит обновление / вставка / удаление в целевых таблицах в вашей базе данных, и кажется, что триггеры CLR SQL расширяют эту функцию до управляемого кода:

http://msdn.microsoft.com/en-us/library/938d9dz2(VS.80).aspx

не эксперт в этом вопросе, но, надеюсь, это даст вам что-то полезное.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...