WPF & Linq to Entities: Как я могу динамически отображать данные, когда они изменяются другим пользователем?

Question

заранее извиняюсь за вопрос noob, я использую WPF всего несколько недель, а SQL Server - несколько дней, но пока не могу найти, как это сделать в Интернете.

У меня есть база данных на SQL Server с одной таблицей в ней «Пользователь», и у меня есть приложение, которое может отображать данные (имя пользователя) из этой таблицы в ListView, используя привязки, которые отлично работают.

Однако, если в базе данных есть элементы, добавленные / удаленные и т. Д. С помощью чего-либо, кроме приложения, изменения автоматически не отражаются в ListView. Я думал, что Bindings позаботится об этом, но, может быть, это только в том случае, если само приложение изменяет данные?

XAML:

<Window.Resources>
    <DataTemplate x:Key="ShowUser" DataType="{x:Type db:User}">
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="{Binding Path=Username}" />
        </StackPanel>              
    </DataTemplate>
</Window.Resources>
...
    <ListView Grid.Row="2" x:Name="TheListView" ItemTemplate="{StaticResource ShowUser}">            

Код:

    public MainWindow()
    {
        InitializeComponent();

        MyDBEntities db = new MyDBEntities();
        var users = from u in db.Users
                    select u;

        IListSource query = (IListSource)users;
        TheListView.ItemsSource = query.GetList();
    }

Что мне нужно сделать, чтобы динамически обновлять ListView при изменении содержимого базы данных чем-то другим, кроме самого приложения?

Заранее спасибо, Daniel

Answer 1

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

Одно грубое решение - опросить базу данных на предмет изменений. Я не уверен в синтаксисе EF, но, возможно, есть какой-то способ «обновить» запрос.

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

Если вы добавили третий уровень, было бы легко перехватить, когда кто-то вносит изменения в данные (до их отправки в базу данных), после чего вы не можете отправить копию изменений всем клиенту. В этой архитектуре часто лучше думать о БД как о просто «тупом» механизме персистентности за вашим средним уровнем (где происходят все умные вещи).

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