Аннотация: В данной лекции описывается, как осмысленно выбрать место для хранения настроек приложений, как определять наилучшее место для хранения различных типов пользовательских настроек, как принимать решение о том, где хранить XML-данные и выбирать место для хранения файлов внешних приложений
Ключевые слова: RDL
С появлением усовершенствованных в отношении производительности и более гибких ядер баз данных, как, скажем, в Microsoft SQL Server 2005, размывается граница между теми объектами, которые следует хранить в базах данных, и теми, которые хранить в них не следует. Раньше базы данных хорошо подходили для хранения только структурированных данных. Однако благодаря недавним достижениям в сфере технологий механизмов баз данных становится все более простым и более выполнимым хранение в базе данных и неструктурированных данных, таких, как документы и изображения. Хранить ли в базе данных все или только некоторые из данных внешних приложений, зависит от того, как эти данные используются.
Где бесплатно хранить фото в 2022
В этой лекции рассказывается о том, как хранить настройки приложений в базе данных. Кроме того, вы узнаете, как манипулировать пользовательскими настройками, сохраняемыми в базе данных. Поскольку XML представляет собой естественный способ хранения иерархических данных, приводятся также подробные сведения об XML-данных. В завершение рассматривается хранение в базе данных больших объектов, для чего обычно используются отдельные файлы.
Где хранить настройки приложений
В программировании на платформе .NET для хранения данных приложений обычно используются XML-документы (обычно с расширением . config ). Если необходимо, чтобы приложение демонстрировало различное поведение в разных ситуациях, возникают сложности. Необходимо либо предусмотреть это в файле конфигурации, либо рассмотреть вариант с применением архитектуры параметров, управляемых данными, при которой для настройки приложения используются данные. Если вы выберете последнее решение, то база данных будет естественным местом для хранения данных, которые управляют настройками приложения.
Прежде чем выбрать модель управления настройками с помощью данных, следует сначала учесть некоторые доводы в пользу использования в приложении конфигурационных файлов. Если ваше приложение не нуждается в базе данных для какой-либо еще функции, возможно, не стоит включать в приложение базу данных только для параметров приложения. Аналогично, если приложение нуждается в параметрах уже в процессе загрузки, а на этом этапе процесса база данных обычно недоступна, то конфигурационный файл будет более естественным решением. (Раньше параметры приложения в подобных ситуациях обычно хранились в реестре Windows, но сейчас они чаще хранятся в конфигурационных файлах приложения.) Одним из главных преимуществ хранения параметров конфигурации приложения в файле является то, что этим файлом с легкостью могут манипулировать пользователи. XML-файл можно редактировать в Блокноте, поэтому любой пользователь может изменить параметры. Если необходимо предотвратить просмотр или изменение уязвимых настроек пользователями, то файлы конфигурации можно зашифровать.
Где Хранить Информацию? Какие Устройства Самые Надёжные? Урок №12
Несмотря на недоступность в процессе запуска приложения, хранение параметров приложения в базе данных может быть выгодным. В базе данных можно управлять доступом к параметрам при помощи политики безопасности базы, в том числе, используя шифрование в SQL Server 2005.
Это не даст пользователям, которые, возможно, не вполне представляют себе последствия сделанных изменений, возможности изменить параметры. Если вы используете какой-либо вариант ролевой модели безопасности (см. лекции 2-3), можно контролировать, кому предоставляется возможность изменять отдельные параметры приложения.
Сохранение параметров приложения в базе данных будет также очень полезно в распределенных приложениях. Таким образом, вы сможете хранить такие разные параметры, как часовой пояс или офисные правила, в одном месте — базе данных. Эти параметры можно настроить так, чтобы приложение хранило различные версии настроек для разных пользователей или групп пользователей, а контролировать параметры смогут сотрудники, имеющие достаточную квалификацию. В табл. 1.1 показаны преимущества, предлагаемые каждым из двух вариантов.
Совет. Если вы хотите использовать преимущества, предоставляемые хранением параметров в базе данных, но не хотите утяжелять клиент полнофункциональной базой данных, подумайте о реализации хранения параметров приложения в базе данных средствами программы Microsoft SQL Server 2005 Express Edition, которая распространяется бесплатно, или Microsoft SQL Server 2005 Workgroup Edition, стоимость которой является убедительным доводом в пользу ее применения для небольших реализаций.
| Пользователь может легко изменить параметры | ? |
| Приложение не требует для работы ядра СУБД | ? |
| Параметры доступны в процессе загрузки приложения | ? |
| В приложении можно реализовать ролевую модель обеспечения безопасности | ? |
| В приложении можно реализовать централизованное управление параметрами | ? |
| В приложении можно легко ограничить доступ к параметрам | ? |
| В приложении может быть обеспечен гранулярный контроль над параметрами | ? |
Как вы уже поняли из сравнения двух методов в табл. 1.1, следует выбрать тот вариант, который лучше подходит для вашего приложения. Не существует однозначного ответа на вопрос, где хранить параметры приложения — в базе данных или в конфигурационном файле. Взвешенно оцените свои потребности и среду и используйте приведенную здесь информацию для принятия такого решения, которое наилучшим образом соответствует требованиям вашего приложения.
Где хранить пользовательские настройки
Часто приложению необходимо хранить информацию о предпочтениях пользователей. В веб-приложениях это обычно реализуется при помощи файлов cookie (небольших текстовых файлов, которые хранят информацию о пользователях), но ввиду возросших требований к обеспечению безопасности в интернете такой подход может оказаться проблематичным.
При использовании некоторых видов идентификации пользователей пользовательские настройки можно хранить в базе данных. Это позволит управлять этими настройками, не обращаясь к клиентскому компьютеру. В базе данных можно хранить самые разные пользовательские настройки.
Эти настройки можно хранить в виде XML-данных, которые обеспечивают максимальную гибкость (о хранении XML-данных будет рассказано далее в этой лекции). Можно также использовать стандартные методы работы с данными для отслеживания пользовательских настроек. Если для хранения пользовательских настроек используется SQL Server, то пользователь может переносить их с одного клиента на другой.
Реализация таблицы пользовательских настроек
- Определите, какие параметры вам необходимо хранить. Хотя в базе данных приложения можно хранить все пользовательские настройки, важно решить, какие параметры необходимы для обеспечения функционирования приложения в особых случаях, а какие параметры должны быть доступными при любом входе пользователя в систему, с какого бы клиента этот вход не выполнялся.
- После того, как вы определите, какие параметры нужно хранить, разработайте необходимую для хранения параметров таблицу. табл. 1.2 представляет собой примерный проект таблицы для управления пользовательскими настройками в базе данных.
| Идентификатор пользователя | Хранит уникальный идентификатор пользователя, который может использоваться для идентификации и возврата пользовательских настроек. Тип данных этого столбца будет зависеть от реализации идентификаторов пользователей в приложении. |
| Дата добавления пользователя. | В этот столбец записывается дата добавления Первая запись о пользовательских настройках обычно создается после добавления пользователя. |
| Дата обновления настроек | Помогает управлять активными пользователями и проверять актуальность их настроек. Обновление данных часто является более важным, чем их создание. |
| Последний вход в систему | Сохраняет информацию о последнем входе пользователя в систему. В некоторых случаях эта информация дублирует информацию в столбце Дата обновления настроек. В зависимости от реализации столбца даты обновления, можно отказаться от данного столбца и использовать только столбец Дата обновления. |
| Столбец или столбцы для хранения пользовательских настроек | В этот столбец записываются пользовательские настройки, которые необходимо сохранить. |
Существует две распространенных реализации столбцов пользовательских настроек. Первая реализация — реляционная. Каждая настройка в этой реализации хранится в отдельном столбце таблицы. С этим решением связана следующая проблема: чтобы добавить дополнительную настройку, придется расширять таблицу путем добавления столбца.
Второй вариант — все пользовательские настройки хранятся в одном столбце. С появлением XML можно использовать XML-документ для хранения нужных настроек либо в столбце TEXT , либо в столбце с типом данных XML; об этом речь пойдет далее в этой лекции.
- Хранимая процедура Insert . С помощью этой процедуры добавляется начальная запись пользовательских настроек. Часто это делается при добавлении пользователя, поэтому данную процедуру можно объединить с процедурой добавления пользователя.
- Хранимая процедура Update . Обновляет запись пользовательских настроек. Эта процедура часто вызывается для управления пользовательскими настройками в приложении.
Важно. При отслеживании часто изменяющихся данных в таблице пользовательских настроек администратору придется активно наблюдать за производительностью и при необходимости регулировать работу реализации. Это особенно верно, если пользовательские настройки обновляются не просто для входа в приложение и выхода из него, но также и для других событий.
Где хранить XML-документы
Несколько лет назад XML-документы были новым веянием, но сейчас они уже стали привычными. Весьма вероятно, что вы уже видели и применяли XML-документы для настройки конфигурации и других задач в приложениях, с которыми работали. В SQL Server 2005 и Microsoft .NET Framework XML-документы широко используются для настройки параметров конфигурации и реализации других функций, таких, как службы интеграции SQL Server Integration Services (для которых XML хранятся в файлах .dtsx ) и службы составления отчетов SQL Server Reporting Services (данные XML хранятся в файлах с расширением . rdl ). XML имеет ряд преимуществ, не последнее из которых — гибкость при изменении требований к конфигурации приложения. Как было отмечено ранее, файлы XML также дают возможность пользователям приложения легко изменять параметры конфигурации.
XML также прекрасно справляется с хранением иерархических данных. Вот несколько примеров иерархических данных: магазинные чеки, спецификации материалов и счета за медицинское обслуживание. Все они включают родительские записи с дочерними записями разных уровней. Извлечение полных наборов этих данных из механизма базы данных может быть затруднено, но XML хранит данные в форме, позволяющей легко просмотреть данные. Поскольку XML очень эффективен и все более широко используется, разработчики компании Microsoft включили в SQL Server 2000 и SQL Server 2005 тип данных XML, а также реализовала особый механизм оптимизации и операторы T-SQL для управления XML-данными.
Примечание. XML-документы уже широко применяются для совместного использования информации внутренними и внешними потребителями в различных сферах бизнеса. В частности, приложения, используемые в здравоохранении, используют XML-схемы для организации совместного использования данных внешними партнерами и внутренними системами лечебных учреждений. Программный пакет Microsoft BizTalk Server 2006 разработан для управления бизнес-процессами и интеграции в подобных ситуациях и для этой цели использует XML-документы.
Поддержка XML в SQL Server 2005
В SQL Server 2005 разработчиками Microsoft в механизм базы данных были добавлены несколько новых специфических XML-функций. Эти усовершенствования позволили облегчить доступ к XML-данным и манипуляции с ними. Ниже перечислены некоторые из таких усовершенствований:
- Собственный тип данных XML
- Поддержка XML-схем
- Возможность использования запросов XQuery к XML-данным, которые хранятся в столбцах с типом данных XML и в переменных
- Возможность индексировать XML-данные, которые хранятся в столбцах XML
- Поддержка языка манипулирования данными XML (XML-DML)
- Усовершенствование существующих функций SQL Server 2000 для работы с XML, в том числе добавление ключевых слов OPENROWSET , FOR XML и OPENXML
Источник: intuit.ru
Как хранить данные в программе?
Допустим, у меня есть программа, которая использует некоторые данные, такие как зависимость ускорения свободного падения от широты. Я создаю статический класс, со статическим словарём, в котором «вбиты» все эти данные. Является ли такой подход правильным и рациональным? Если нет, как лучше хранить данные в таком случае?
Отслеживать
задан 21 ноя 2016 в 14:02
91 1 1 серебряный знак 3 3 бронзовых знака
константы еще никто не отменял, но этих величин может быть много, думается мне, я бы намутил файл, xml, записал наконец в бд, если такая имеется
21 ноя 2016 в 14:09
Все зависит от объема данных, требований, возможностей хранения на файловой системе, в базе данных и т.д. По поводу организации классов это уже другой вопрос. Можно и константные значения использовать, если это детерминированые физические величины
21 ноя 2016 в 14:12
Если вам дан исчерпывающий ответ, отметьте его как верный (галка напротив выбранного ответа).
22 ноя 2016 в 5:56
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
Подходов для хранения данных немало, в том числе справедлив и тот, что указали вы. Но на самом деле хорошей практикой считается отделение кода от данных, т.е. данные отдельно, а программа отдельно.
Основная и самая весомая причина для этого — если вдруг у вас поменяются данные, а они зашиты (захардкоджены) в программу, то в случае изменения данных программу придется перекомпилировать. Если же данные хранятся отдельно, то их можно поменять тоже отдельно, без перекомпиляции программы.
Смотрите сами на характер ваших данных — если это преимущественно константы, т.е. значения по типу числа пи, ускорения свободного падения и т.д., то да, вероятно, имеет смысл объявить их в коде. Либо можно записать их в ресурсы программы, в этом случае они будут как бы отдельно, но вшиты в тело сборки (в бинарник ваш).
В противном случае вы можете хранить данные в XML-файле, в файле App.config, в простом текстовом или INI-файле, даже в реестре Windows, или в таблице (таблицах) базы данных (например, в SQLite).
Рекомендуемый способ — XML и App.config (тоже XML по сути), но вы вольны выбрать то, с чем вам проще и удобнее работать.
UPD. Уже после ответа отыскалась статья на Хабре, посвященная хранению настроек приложения.
Отслеживать
ответ дан 21 ноя 2016 в 14:13
BlackWitcher BlackWitcher
2,756 13 13 серебряных знаков 33 33 бронзовых знака
На первых порах подход хороший, и вам не нужно предусматривать заранее все возможные случаи. (Попытка учесть вообще всё на начальном этапе называется overengineering.)
Я бы всё же посоветовал использовать не статический класс, а экземпляр, доступный в статическом месте, потому что это позволит легче изменять код, если нужно (и не стоит практически ничего).
Возможные направления развития:
- У вас появятся разные планеты? Тогда у вас будут несколько таких классов, по одному для планеты.
- Вам нужно конфигурировать это на машине клиента? Тогда нужно будет считывать данные из конфигурационного файла.
Но не делайте это сейчас. Не пытайтесь предусмотреть возможные пути развития в начале разработки, подождите, пока это потребует заказчик.
Отслеживать
ответ дан 21 ноя 2016 в 14:12
206k 27 27 золотых знаков 290 290 серебряных знаков 521 521 бронзовый знак
Если по данными вы подразумеваете некоторые относительно постоянные физические величины и законы (относительно постоянные, потому что иногда вносятся уточнения в константы, да и законы иногда пересматривают, в истории науки примеров достаточно) то в принципе вы на правильном пути, но я делал немного иначе в проекте по моделированию вакуумных процессов.
- Статический класс по аналогии System.Math , это у вас уже есть.
- Константы задаются в виде свойств, не констант или полей, а именно свойств, почему станет понятно позже.
- Этот класс или набор классов, для логической группировки величин и законов, компилируются в виде отдельной библиотеки, которую подключаем к программе.
Теперь о константах заданных свойствами. На первый взгляд, разницы между константным свойством и константой нет, но это только на первый взгляд. Вспоминаем что свойство это метод, в случае с константами один, условно get . Это дает одно, но существенное преимущество. Константа при компиляции намертво встраивается в код в тех местах, где вы к ней обращаетесь.
Поэтому даже если вы замените константу в библиотеке, то для того, чтобы она попала в код, использующий эту библиотеку, придется его повторно компилировать. В случае со свойствами перекомпиляция не потребуется, вы можете безболезненно заменить устаревшую библиотеку на обновленную, если сигнатуры публичных методов и список методов остались неизменными (список методов может быть расширен в новой версии). Т.о. у вас появляется возможность вносить уточнения в точность констант и алгоритмы вычисления величин, а также заменить константное свойство на вычисляемое, без необходимости пересобирать всю программу.
Вариант хранить подобные величины в БД или файле конфигурации конечно можно применить, но не думаю что давать пользователю возможность править физические законы будет хорошей идеей, особенно если последний плохо знаком с предметной областью.
Другие возможные варианты уже описаны в соседних ответах.
Источник: ru.stackoverflow.com
10 вариантов хранения данных на стороне клиента
Ситуации для хранения и обработки данных в браузере включают:
сохранение состояния клиентского приложения, такого как текущий экран, введенные данные, пользовательские настройки и т. д.
утилиты, которые обращаются к локальным данным или файлам и имеют строгие требования к конфиденциальности
прогрессивные веб-приложения (PWA), которые работают в автономном режиме
Онлайн курс по JavaScript
Научитесь создавать приложения со сложными интерфейсами
Это основной язык для современной веб-разработки — почти 100% сайтов работает на JavaScript. Освойте его с нуля всего за 4 месяца, и вы сможете зарабатывать от 70 000 рублей.
Вас ждут 2 уровня по программированию на JavaScript
Подходит для новичков без опыта в программировании
Практика на вебинарах с разработчиками из крупных компаний
Вот десять вариантов хранения данных браузера:
1. JavaScript переменные
2. Хранилище узлов DOM
3. Web хранилище (localStorage и sessionStorage)
5. Cache API (не используйте AppCache!)
6. API доступа к файловой системе
7. API записей файлов и каталогов
В этой статье рассматриваются эти десять различных способов хранения данных в браузере, рассматриваются их ограничения, плюсы и минусы, а также наилучшее использование каждого метода. Прежде чем мы перейдем к вариантам, сделаем небольшое примечание о сохранении данных.
Сохранение данных
Как правило, данные, которые сохраняются, будут:
Постоянные (persistent): они остаются до тех пор, пока ваш код не решит удалить их, или
изменяемые (volatile) : они остаются до завершения сеанса браузера, обычно, когда пользователь закрывает вкладку
Постоянные данные могут быть заблокированы или удалены пользователем, операционной системой, браузером или плагинами в любой момент. Браузер может принять решение об удалении более старых или больших элементов по мере приближения к граничной емкости, выделенной для этого типа хранилища.
Браузеры также записывают состояние страницы. Вы можете уйти с сайта и кликнуть назад или закрыть и снова открыть вкладку; страница должна выглядеть идентично. Переменные и данные, доступные только для сеанса, по-прежнему доступны.
1. Переменные JavaScript
размер — нет строгих ограничений, но при заполнении памяти может произойти замедление работы браузера или сбои
скорость чтения / записи — самый быстрый вариант
сохранность — плохая: данные стираются при обновлении браузера
Сохранение состояния в переменных JavaScript — самый быстрый и простой вариант. Я уверен, что вам не нужен пример, но …
JavaScript
msg : ‘Hello’ ,
name : ‘Craig’
нет необходимости в сериализации или десериализации
ненадежность: обновление или закрытие вкладки стирает все
сторонние скрипты могут исследовать или перезаписывать глобальные значения (window). Вы уже используете переменные. Вы можете рассмотреть возможность сохранения состояния переменной при выгрузке страницы.
2. Хранилище узлов DOM
размер — нет строгих ограничений, но не идеально для большого количества данных
скорость чтения / записи — Быстрый
сохранность — плохая: данные могут быть удалены другими скриптами или обновлением
Большинство элементов DOM на странице или в памяти могут хранить значения в именованных атрибутах. Безопаснее использовать имена атрибутов с префиксом data-:
атрибут никогда не будет иметь связанных функций HTML
Вы можете получить доступ к значениям с помощью свойства dataset или через методы .setAttribute() и .getAttribute().
Значения хранятся в виде строк, поэтому может потребоваться сериализация и десериализация. Например:
JavaScript
// locate element
const main = document . querySelector ( ‘main’ ) ;
// store values
main . dataset . value1 = 1 ;
main . dataset . state = JSON . stringify ( < a : 1 , b : 2 >) ;
// retreive values
console . log ( main . dataset . value1 ) ; // «1»
console . log ( JSON . parse ( main . dataset . state ) . a ) ; // 1
вы можете определять значения в JavaScript или HTML, например
полезно для хранения состояния конкретного компонента
DOM работает быстро! (вопреки распространенному мнению)
ненадёжно: обновление или закрытие вкладки стирает значения
только строки: требуется сериализация и десериализация
большой DOM влияет на производительность
сторонние скрипты могут исследовать или перезаписывать значения
Хранилище узлов DOM работает медленнее, чем переменные. Используйте его экономно в ситуациях, когда удобно хранить состояние компонента в HTML.
3. Web хранилище (localStorage и sessionStorage)
размер — 5 МБ на домен
скорость чтения / записи — синхронная работа: может быть медленной
сохранность — данные остаются до тех пор, пока не будут удалены
Веб-хранилище предоставляет два похожих API для определения пар имя/значение. Используйте:
window.localStorage для хранения постоянных данных и
window.sessionStorage для сохранения данных только сеанса, пока вкладка браузера остается открытой
Храните или обновляйте именованные элементы с помощью .setItem():
JavaScript
localStorage . setItem ( ‘value1’ , 123 ) ;
localStorage . setItem ( ‘value2’ , ‘abc’ ) ;
localStorage . setItem ( ‘state’ , JSON . stringify ( < a : 1 , b : 2 , c : 3 >) ) ;
Получайте их с помощью .getItem():
JavaScript
const state = JSON . parse ( localStorage . getItem ( ‘state’ ) ) ;
И удалите их с помощью .removeItem():
JavaScript
localStorage . removeItem ( ‘state’ )
Другие свойства и методы включают:
.length: количество хранимых элементов
.key(N): имя N-го ключа
.clear(): удаление всех сохраненных элементов
Изменение любого значения вызывает событие хранения в других вкладках / окнах браузера, подключенных к тому же домену. Ваше приложение может ответить соответствующим образом:
JavaScript
window . addEventListener ( ‘storage’ , s = > <
console . log ( ` item changed : $ < s . key >` ) ;
console . log ( ` from value : $ < s . oldValue >` ) ;
console . log ( ` to new value : $ < s . newValue >` ) ;
простой API (пары имя / значение)
параметры сеанса и постоянного хранилища
хорошая поддержка браузера
Только строки: требуется сериализация и десериализация
неструктурированные данные без транзакций, индексации или поиска
синхронный доступ повлияет на производительность больших наборов данных
Веб-хранилище идеально подходит для простых, небольших и разовых значений. Оно менее практично для хранения больших объемов структурированной информации, но вы можете избежать проблем с производительностью, записывая данные при выгрузке страницы.
4. IndexedDB
размер — зависит от устройства. Не менее 1 ГБ, но может составлять до 60% оставшегося дискового пространства
скорость чтения / записи — быстрый
сохранность — данные остаются до тех пор, пока не будут удалены
IndexedDB предлагает низкоуровневый API, похожий на NoSQL, для хранения больших объемов данных. Хранилище можно индексировать, обновлять с помощью транзакций и выполнять поиск с помощью асинхронных методов.
IndexedDB API сложен и требует некоторого манипулирования событиями. Следующая функция открывает соединение с базой данных при передаче имени, номера версии и дополнительной функции обновления (вызываемой при изменении номера версии):
JavaScript
function dbConnect ( dbName , version , upgrade ) <
return new Promise ( ( resolve , reject ) = > <
const request = indexedDB . open ( dbName , version ) ;
request . onsuccess = e = > <
resolve ( e . target . result ) ;
request . onerror = e = > <
console . error ( ` indexedDB error : $ < e . target . errorCode >` ) ;
request . onupgradeneeded = upgrade ;
Следующий код подключается к базе данных myDB и инициализирует хранилище объектов todo (аналогично таблице SQL или MongoDB). Затем он определяет автоматически увеличивающийся ключ с именем id:
JavaScript
const db = await dbConnect ( ‘myDB’ , 1.0 , e = > <
db = e . target . result ;
const store = db . createObjectStore ( ‘todo’ , < keyPath : ‘id’ , autoIncrement : true >) ;
Как только соединение будет готово, вы можете с помощью .add добавить новые элементы данных в транзакцию:
JavaScript
db . transaction ( [ ‘todo’ ] , ‘readwrite’ )
. objectStore ( ‘todo’ )
. onsuccess = ( ) = > console . log ( ‘added’ ) ;
И вы можете получить значения, например, первый элемент:
JavaScript
db . transaction ( [ ‘todo’ ] , ‘readonly’ )
. objectStore ( ‘todo’ )
. onsuccess = data = > console . log ( data . target . result ) ;
гибкое хранилище данных с самым большим пространством
надежные транзакции, возможности индексации и поиска
хорошая поддержка браузера
сложный обратный вызов и API на основе событий
IndexedDB — лучший вариант для надежного хранения больших объемов данных, но вам может понадобиться библиотека-оболочка, такая как idb, Dexie.js или JsStore.
5. Cache API
размер — зависит от устройства, но Safari ограничивает каждый домен до 50 МБ
скорость чтения / записи — быстрый
сохранность — данные остаются до очистки или через две недели в Safari
Cache API обеспечивает хранение для пар HTTP запросов и ответов. Вы можете создать любое количество именованных кэшей для хранения любого количества элементов данных сети.
API обычно используется в сервис-воркерах для кэширования сетевых ответов для прогрессивных веб-приложений. Когда устройство отключается от сети, кэшированные ресурсы могут быть повторно использованы, чтобы веб-приложение могло работать в автономном режиме. Следующий код сохраняет сетевой ответ в кэше с именем myCache:
JavaScript
// cache name
const cacheName = ‘myCache’ ;
// cache network response
const stored = await cacheStore ( ‘/service.json’ ) ) ;
console . log ( stored ? ‘stored OK’ : ‘store failed’ ) ;
// store request
async function cacheStore ( url ) <
// open cache
const cache = await caches . open ( cacheName ) ;
// fetch and store response
await cache . add ( url ) ;
return true ;
catch ( err ) <
return undefined ; // store failed
Аналогичная функция может получить элемент из кеша. В этом примере она возвращает основной текст ответа:
JavaScript
// fetch text from cached response
const text = await cacheGet ( ‘/service.json’ ) ) ;
console . log ( text ) ;
async function cacheGet ( url ) <
// open cache
cache = await caches . open ( cacheName ) ,
// fetch stored response
resp = await cache . match ( url ) ;
// return body text
return await resp . text ( ) ;
catch ( err ) <
return undefined ; // cache get failed
хранит любой сетевой ответ
может улучшить производительность веб-приложений
позволяет веб-приложению работать в автономном режиме
не практично для хранения состояния приложения
возможно менее полезно за пределами прогрессивных веб-приложений
Apple недоброжелательно относится к PWA и Cache API
Cache API — лучший вариант для хранения файлов и данных, полученных из сети. Вы, вероятно, могли бы использовать его для хранения состояния приложения, но он не предназначен для этой цели, и есть варианты получше.
5.5 AppCache
AppCache был предшественником Cache API. Это не то решение для хранения, которое вы ищете. Здесь ничего нет. Пожалуйста, двигайтесь дальше.
6. API доступа к файловой системе
размер — зависит от оставшегося места на диске
скорость чтения / записи — зависит от файловой системы
сохранность — данные остаются до тех пор, пока не будут удалены
API доступа к файловой системе позволяет браузеру читать, записывать, изменять и удалять файлы из локальной файловой системы. Браузеры работают в изолированной среде, поэтому пользователь должен предоставить разрешение на определенный файл или каталог. Чтобы веб-приложение могло читать или записывать данные, как настольное приложение, используют FileSystemHandle.
Следующая функция сохраняет объект Blob в локальный файл:
JavaScript
async function save ( blob ) <
// create handle to a local file chosen by the user
const handle = await window . showSaveFilePicker ( ) ;
// create writable stream
const stream = await handle . createWritable ( ) ;
// write the data
await stream . write ( blob ) ;
// save and close the file
await stream . close ( ) ;
веб-приложения могут безопасно читать и записывать в локальную файловую систему
меньше необходимости загружать файлы или обрабатывать данные на сервере
отличная функция для прогрессивных веб-приложений
минимальная поддержка браузера (только Chrome)
API может измениться
Этот вариант хранения для меня очень интересен, но вам придется подождать пару лет, прежде чем он станет жизнеспособным для производственного использования.
7. API записей файлов и каталогов
размер — зависит от оставшегося места на диске
скорость чтения / записи — неизвестный
сохранность — данные остаются до тех пор, пока не будут удалены
API записей файлов и каталогов предоставляют песочницы файловой системы доступной для домена, которые могут создавать, писать, читать и удалять каталоги и файлов.
может иметь несколько интересных применений
нестандартные, несовместимость между реализациями и поведение могут измениться.
MDN прямо заявляет: не используйте это на производственных сайтах . Поддержка будет в лучшем случае через несколько лет.
8. Файлы cookie
размер — 80 КБ на домен (20 файлов cookie размером до 4 КБ в каждом)
скорость чтения / записи — быстрый
сохранность — хорошая: данные остаются до тех пор, пока они не будут удалены или не истечет время их жизни
Файлы cookie — это данные, относящиеся к домену. Они имеют репутацию что они отслеживают людей, но они необходимы для любой системы, которая должна поддерживать состояние сервера, например, для входа в систему. В отличие от других механизмов хранения, файлы cookie (обычно) передаются между браузером и сервером при каждом HTTP-запросе и ответе. Оба устройства могут проверять, изменять и удалять данные cookie.
document.cookie устанавливает значения cookie в клиентском JavaScript. Вы должны определить строку с именем и значением, разделенными символом равенства (=). Например:
JavaScript
document . cookie = ‘cookie1=123’ ;
document . cookie = ‘anothercookie=abc’ ;
Значения не должны содержать запятых, точек с запятой или пробелов, поэтому может потребоваться encodeURIComponent():
JavaScript
document . cookie = ` hello = $ < encodeURIComponent ( ‘Hello, everyone!’ ) >` ;
К дополнительным настройкам файлов cookie можно добавить разделители через точку с запятой, в том числе:
;domain= : если не установлено, то cookie доступен только в текущем домене URL. Использование ;path=mysite.com разрешило бы на любом поддомене mysite.com.
;path= : если не установлено, cookie доступен только в текущем и дочерних доменах. Установите, ;path=/ чтобы разрешить любой путь в домену.
;max-age= : время истечения срока действия cookie в секундах, например ;max-age=60.
;expires= : дата истечения срока действия cookie, например ;expires=Thu, 04 July 2021 10:34:38 UTC(используйте date.toUTCString() для соответствующего форматирования).
;secure: cookie будет передаваться только по HTTPS.
;HTTPOnly: делает файлы cookie недоступными для клиентского JavaScript.
;samesite=: определяет, может ли другой домен получить доступ к cookie. Может иметь значение lax (по умолчанию, использует файл cookie для текущего домена), strict (останавливает отправку исходного файла cookie при переходе по ссылке из другого домена) или none (без ограничений).
Пример: установить файл cookie, срок действия которого истекает через 10 минут и доступен по любому пути в текущем домене:
Источник: webformyself.com