Улучшение предполагаемого времени запуска приложения WPF

Question

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

Я попытался создать пользовательский элемент управления (и выполнить всю загрузку данных) в конструкторе главного окна:
Заставка будет отображаться 5 с, затем 1 с пустого главного окна, пока приложение не будет готово к использованию.
Пользователи говорят, что это занимает слишком много времени, пока что-то (визуально) не произойдет.

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

Существуют ли общие рекомендации относительно предполагаемого времени загрузки приложения или есть другие рекомендации о том, как можно улучшить эту ситуацию?
Я считаю, что в идеале главное окно должно отображаться как можно быстрее, вместе с часами или спиннером, пока данные не будут загружены. Но тогда я не могу просто переместить создание пользовательского элемента управления в фоновый рабочий, поскольку это будет сделано в неправильном потоке.

У кого-нибудь есть предложения по этой проблеме?

Edit:
Обратите внимание, что сейчас я просто назначил запрос LINQ-to-EF в качестве источника данных сетки.
Одним из возможных улучшений может быть загрузка этих данных в таблицу данных в фоновом режиме и назначение их только после загрузки ...

Edit2: Я использую .net 4 с System.Data.SQLite и EF4 для загрузки данных. Более или менее 4000 строк и 30 столбцов.

Answer 1

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

BackgroundWorker bgWorker = new BackgroundWorker() { WorkerReportsProgress=true};  
bgWorker.DoWork += (s, e) => {      
    // Load here your file/s      
    // Use bgWorker.ReportProgress(); to report the current progress  
};  
bgWorker.ProgressChanged+=(s,e)=>{      
    // Here you will be informed about progress and here it is save to change/show progress. 
    // You can access from here savely a ProgressBars or another control.  
};  
bgWorker.RunWorkerCompleted += (s, e) => {      
// Here you will be informed if the job is done. 
// Use this event to unlock your gui 
};  
bgWorker.RunWorkerAsync();  

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

Обновление

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

Попробуйте проверить, есть ли в вашем интерфейсе что-то, что мешает DataGrid виртуализировать элементы.Может быть, у вас есть проблема?Для анализа приложений WPF я могу порекомендовать вам Инструменты профилирования WPF .

Answer 2

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

Один урок, который я усвоил, заключается в том, что если вы используете ORM, при загрузке больших наборов данных, если вы предпочитаете POCO (простые старые объекты CLR / C #) над сгенерированными ORM объектами базы данных (см. Пример ниже), время загрузки будет намного быстрее, и использование оперативной памяти будет значительно уменьшено. Причина этого заключается в том, что EF попытается загрузить всю сущность (то есть все ее поля) и, возможно, всю загрузку данных, связанных с вашими сущностями, большинство из которых вам даже не понадобятся. Единственный раз, когда вам действительно нужно работать напрямую с сущностями, это когда вы выполняете операции вставки / обновления / удаления. При чтении данных вы должны только получать поля, которые ваше приложение должно отображать и / или проверять.

Если вы следуете шаблону MVVM, описанную выше архитектуру несложно реализовать.

Пример загрузки данных в POCO с EF:

var query = from entity in context.Entities
                select new EntityPoco
                {
                    ID = entity.ID,
                    Name = entity.Name
                };

return query.ToList();

POCO - это очень простые классы с автоматическими свойствами для каждого поля.

У нас обычно есть репозитории для каждого объекта в наших приложениях, и каждый репозиторий отвечает за получение / обновление данных, связанных с этим объектом. Модели представлений имеют ссылки на нужные им репозитории, поэтому они не используют EF напрямую. Когда пользователи вносят изменения, которые необходимо сохранить, мы используем другие методы в хранилище, которые затем загружают только подмножество сущностей (то есть те, которые изменил пользователь) и применяют необходимые обновления - с некоторой проверкой, выполненной моделью представления, и, возможно, другой проверкой происходит в БД через ограничения / триггеры и т. д.

Answer 3

Для этого есть много причин.

1) Машина развертывания может иметь довольно низкую конфигурацию.2) Неправильно или проблема с привязкой данных.

Возможные решения:1) Ленивая загрузка данных2) Оптимизировать производительность.http://msdn.microsoft.com/en-us/library/aa970683.aspx

Я видел, как приложения отображают 5M записей менее чем за секунду в wpf.

PS: Еще одна наименее вероятная причина - 30 столбцов из-за доступа к порядку столбцов.