Концепция «Каталог данных» на каждой платформе

Question

Это очень похоже на Где кроссплатформенные приложения должны хранить свои данные? , но немного расширить их.

Есть несколько полезных советов о том, где должен находиться родительский каталог для данных, но не настолько, как о каков каталог данного приложения.

Например, допустим, у нас есть кроссплатформенное приложение, написанное My Corp. в рамках My Brand, под названием My App. Предположим, что есть другие продукты в My Brand, которые, по-видимому, хотят иметь свои собственные данные, а также другие бренды в My Corp. Где должны храниться его данные и / или конфигурация в Windows? В Unix? Mac OS9? Mac OS X? Другое

например, в Windows данные помещались бы в "... \ Application Data \ My Corp \ My Brand \ My App", в то время как в Mac OS X данные помещались в ~ / Library / Application Support / My Corp / My Brand / My App ", а в Unix оно будет помещено в" ~ / .mycorp / mybrand / myapp "? (Я полагаю, другие платформы будут использовать искажение unix, даже если базовый каталог может отличаться.)

Если нет реального соглашения, кажется ли это разумным? Любые предложения для Mac OS9?

Answer 1

Просто чтобы начать отражение:

Вы должны сделать четкую разницу между:

• приложение состояние данные
• Настройки
• данные (могут быть общими для нескольких приложений)

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

Данные, представляющие состояние приложения, могут помещаться в «Данные приложения», как указано в вопросе « где кросс-платформенные приложения хранят свои данные? ».

Но настройки ... Зависит от того, нужно ли запускать ваше приложение с несколькими "конфигурациями":

• по одному для каждой платформы: в случае, если вы должны управлять ими на этапе разработки, и упаковать этот файл на этапе выпуска, чтобы сохранить его в «Прикладных данных»
• много для платформы одна , например, с разными размерами кучи или с разными настройками, представляющими различные операции, которые будут выполняться вашим приложением. И это приводит к взрыву файлов настроек (также хранящихся в различных подкаталогах «Application Data»)
  Именно здесь идея абстрагирования этих данных в Setting Provider является хорошей идеей.

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