Поддержание локального кэша активов

Question

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

Часть этой системы заключается в том, что мне нужно синхронизировать ресурсы между сервером и клиентом. Сервер хранит все активы в файле .zip или в виде структуры каталогов в файловой системе; Я еще не решил. Эти активы могут измениться: активы могут быть добавлены, удалены или изменены. Эти модификации должны быть синхронизированы с клиентом.

У меня проблема в том, как сохранить эти активы на клиенте. Я сформулировал следующие требования:

• Активы имеют ключи, подобные ключам пути (например, Images/Icons/16/add.png);

• CRC32 должен поддерживаться для каждого актива для обнаружения ошибок;

• Будет примерно от 100 до 200 активов;

• Размер активов будет варьироваться от 1 КБ до 500 КБ (только один или два); средний размер - 8 КБ; в основном .png файлы изображений;

• Поскольку загруженные ресурсы будут кэшироваться в памяти, поиск не должен быть слишком быстрым;

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

Я придумал следующие подходы:

• Файлы на диске. Это имеет следующие преимущества:

  • Простота реализации;

  • Быстрое обновление и поиск;

  И следующие недостатки:

  • Множество файлов "где-то" на диске;

  • Невозможно сохранить метаданные (CRC32);

• Хранение файлов в файле .zip. Это имеет следующие преимущества:

  • Четко определенный механизм хранения с хорошей поддержкой .NET;

  • Поддерживает CRC32 для меня (я считаю);

  И следующие недостатки:

  • Обновление и поиск случайных файлов происходит относительно медленно (я считаю);

  • Невозможно сохранить дополнительные метаданные (хотя я не знаю, понадобится ли мне это);

• Хранение файлов в базе данных SQLite. Это имеет следующие преимущества:

  • Четко определенный механизм хранения с хорошей поддержкой .NET;

  • Позволяет хранить все виды метаданных;

  • Быстрое обновление и поиск случайных файлов;

  И следующие недостатки:

  • Может быть полностью излишним;

  • Меня беспокоит бинарная поддержка SQLite.

У меня вопрос 1. Я пропускаю очевидную альтернативу и / или 2. Какой подход будет наилучшим.

Answer 1

Подход к подходу KISS: просто загрузка всего файла ресурсов на клиент.

Библиотеки ресурсов не получат такого большого размера, от 1 МБ до 2 МБ.Весь файл .zip может быть проверен на наличие изменений с помощью одного хэша и обновлен только после изменения.Поскольку это случается не часто (не чаще одного раза в месяц), это не будет проблемой.

Answer 2

Лично я бы пошел с SQLLite (или MySql, который с открытым исходным кодом и бесплатный).

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