Concept de "Data Directory" sur chaque plate-forme

Question

Ceci est très similaire à Where should cross-platform apps keep their data?, mais en expansion un peu.

Il existe de bons conseils sur l'emplacement du répertoire parent pour les données, mais pas beaucoup sur ce que doit être le répertoire d'une application donnée. Par exemple, supposons que nous ayons une application multiplate-forme, écrite par My Corp, dans My Brand, appelée My App. Supposons qu'il y a d'autres produits dans My Brand qui veulent probablement leurs propres données, ainsi que d'autres marques dans My Corp. Où ses données et/ou configuration devraient-elles aller sur Windows? Sur Unix? Mac OS9? Mac OS X? Autre? Par exemple, sur Windows, les données iraient dans "... \ Application Data \ Mon Corp \ My Brand \ Mon App", tandis que sur Mac OS X les données iraient dans ~/Library/Application Support/My Corp/My Brand/My App "et sur Unix il irait dans" ~/.mycorp/mybrand/myapp "? (J'imagine que d'autres plates-formes utiliseraient le mangling d'unix, même si le répertoire de base est différent.)

S'il n'y a pas de convention réelle, cela semble raisonnable des suggestions pour Mac OS9

Answer 1

Juste pour commencer la réflexion:?

Vous devez faire une nette différence entre:

• l'application état données
• paramètres
• données (peut être commun pour plusieurs applications)

Ce dernier peut éventuellement être dans une base de données, ou pourrait être géré par un ou plusieurs applications, ou encapsulées par un bus de communication afin d'éviter que toutes les autres applications dialoguent entre elles pour accéder à ces données.

Les données représentant l'état d'une application peuvent aller dans 'Application Data' comme mentionné dans la question "where cross-platform apps keep their data ?".

Mais les paramètres ... Cela dépend si votre application a besoin d'être lancé avec plusieurs « configurations »:

• une pour chaque plate-forme: dans le cas où vous devez les gérer dans la phase de développement, et package déposer dans la phase de libération, afin de le stocker dans « application Data »
• beaucoup pour une plate-forme, comme avec différentes tailles heap, ou différents paramètres représentant les différentes opérations à exécuter par votre même application. Et cela conduit à une explosion des fichiers de réglage (également stockés dans divers sous-répertoire de 'Application Data')
  C'est là que l'idée de l'abstraction de ces données dans un Setting Provider est une bonne idée.

En fait, nous avons tellement de configurations différentes pour nos paramètres que nous les stockons dans une base de données sur une machine de production séparée. De cette façon, toutes les applications peuvent y accéder, mais plus important, nous peut accéder et les modifier en temps réel, sans avoir à arrêter/redémarrer les applications pour chaque modification, ou sans avoir à aller à chaque plate-forme de déploiement.