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

Question

Я создаю приложение WPF (используя MVVM), которое, по своей сути, позволяет пользователям взаимодействовать с базой данных Oracle.

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

Первоначально предполагалось создать единый в масштабах приложения экземпляр класса «хранилище», который будет периодически обновлять свои данные из базы данных, а затем уведомлять (используя MvvmLight. Сообщения), когда происходят обновления.

Первый вопрос; Это разумный подход, или есть лучший способ достичь этого?

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

Answer 1

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

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

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

Answer 2

Более обычный подход заключается в том, чтобы pu sh уведомляет об изменениях.

SignalR является отличным кандидатом для этого.

Обычный шаблон:

Вся база данных обновляет go через уровень сервера приложений.

Каждый клиент регистрирует интерес ко всем или подмножеству данных по этому.

Вызовы через этот сервер затем приводят к тому, что сигнализатор отправляет всех "заинтересованных" клиентов новые данные.

Альтернатива:

Вызов обновлений go через сервер приложений или такой механизм, как RabbitMQ. Это «разделяет» сигнал, поэтому обновляет go в базе данных и в кеше redis или в базе данных памяти.

Клиенты опрашивают кеш.

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

Три варианта многочисленны.

Например, у вас может быть приложение, используемое в Китае, Америке и Европе. Один сервер базы данных содержит все. Может быть, каждая область «интересуется» только данными своей области. Вы можете иметь локальный сервер приложений для каждой области с кэшем redis на еще нескольких локальных машинах.

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

Стоит ли что-то из этого, только вы знаете.

Возможно, у вас много пользователей.

Может быть, вам нужно знать об изменениях в секундах, а не в минутах

Я работал в системе аэропорта несколько лет назад.

IIR C верхний ожидаемый предел составлял около 3000 одновременно работающих пользователей.

Это только что использованный опрос.