Загрузка большого количества предварительных данных. , синхронизация или асинхронность

Question

, поэтому у меня есть приложения winforms, которые загружают набор данных синхронно при запуске. Это, очевидно, занимает некоторое время, но затем, когда какой-либо из сервисов или классов GUI загружается, они все имеют эти данные. Я мог бы изменить это, чтобы включить фоновый поток, но тогда каждый компонент, которому нужен доступ к этим данным, должен был бы постоянно получать уведомление, когда эти данные были готовы. Это кажется плохим дизайном для каждого из моих классов, который зависит от того, какие данные должны быть загружены, чтобы иметь проверку If (Loaded) или подписку на загруженное событие. , , есть идеи?

Есть еще идеи?

Answer 1

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

Заставка

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

Подписка

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

Ленивая загрузка

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

Answer 2

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

Загрузка данных по сравнению с отложенной загрузкой - это настройка для каждого приложения. Я бы построил центральный объект данных, который обрабатывает оба сценария. Способ, которым я мог бы рекомендовать сделать это, состоит в том, чтобы создать управляемую событиями модель зависимости. Под этим я подразумеваю, что вы можете поместить функцию регистрации события или обратного вызова на объект диспетчера данных, на который подписываются различные блоки кода, когда им нужно использовать данные, и затем они отзываются, когда данные доступны. Если данные уже доступны, обратный вызов происходит немедленно. Иначе, блок кода вызывается обратно, когда данные загружаются из фонового потока. Например, в каком-то окне или компоненте у вас может быть какой-то код, похожий на:

DataManager.LoadDataAsync(dataCommandPatternObject, CallBackFunction);

...

public void CallbackFunction(SomeDataObjectClass data)
{
    //load data into UI
}

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

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

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

Answer 3

Я бы предложил вам использовать Шаблон наблюдателя и настроить все классы, которые зависят от загружаемого набора данных. Чтобы свести к минимуму количество времени, которое пользователь должен ждать, вы также можете рассмотреть реализованные две категории классов: те, которым нужен весь набор данных, и те, которые могут функционировать после загрузки подмножества данных.

Шаблон проектирования наблюдателя