Melhor maneira de salvar as configurações do aplicativo

17

No Windows, a maneira padrão é o registro. Isso permite diferenciar as configurações de todo o sistema e por usuário.

No Unix, você deve usar arquivos de texto na pasta / etc para configurações em todo o sistema (qual é a convenção para configurações por usuário?).

Muitos programas novos (e especialmente aqueles projetados para serem portáteis) usam arquivos XML.

Qual é a melhor maneira (e local) de armazenar configurações que não sejam BLOB?
Devemos seguir cada padrão do sistema ou ter uma solução unificada?
E qual é a melhor maneira portátil ?

portability

— Wizard79
fonte

Por favor, seja muito específico sobre o que você quer dizer com "melhor".

3

@ Thorbjørn: melhor adj \ melhor \ superlativo do bem

— Wizard79

3

você ficaria surpreso com a diversidade de significados de "melhor" nos sites StackExchange.

23

Qual é a melhor maneira (e local) de armazenar configurações que não sejam BLOB?

No Windows, parece aceitável usar o registro. Na minha opinião, o registro era um sistema mal planejado e, em vez disso, um arquivo de texto simples no Users\Username\AppDatadiretório deveria ser preferido. É mais fácil fazer backup, menos perigoso para os usuários modificarem e mais fáceis de limpar.

No Linux e na maioria dos Unixes, o local preferido é /home/user/.config/appnamepara configurações específicas do usuário e /etc/para configurações globais (em todo o sistema). O local menos preferido (mas aceitável) para as configurações do usuário é ~/.appname, mas isso geralmente está desvalorizando. Esses arquivos devem ser editáveis pelo usuário, portanto, sempre é preferível um formato legível por humanos.

Eu discordo da maioria das pessoas de que XML é um formato aceitável para armazenar dados que não são de blob. É, na minha opinião, um formato exagerado e excessivamente complexo para o que geralmente acaba sendo pedaços muito pequenos de dados estruturados. Prefiro ver arquivos em YAML, JSON, ASN.1, pares nome = valor ou formatos semelhantes. Ter muita sintaxe facilita demais o usuário bagunçar e deixar o arquivo em um formato inválido.

Devemos seguir cada padrão do sistema ou ter uma solução unificada?

Isso depende inteiramente de você, mas lembre-se de algumas coisas:

Plataformas como * nix têm limitações estritas sobre quais locais são graváveis. Mais rigoroso que o Windows. Então:
- O único local para o qual você deve escrever é no diretório inicial do usuário.
- A menos que seu aplicativo seja um serviço do sistema; nesse caso, todos os arquivos de dados mutáveis devem ser gravados /var/. Arquivos de dados Nonmutable deve ser mantido em seu diretório app em /usr/share/ou /usr/local/share/ou/opt/
- Os arquivos de configuração nunca/etc/ devem ser gravados pelo aplicativo quando estiver em execução, mesmo que ele tenha acesso de gravação. deve ser o repositório para comportamentos padrão e nada mais./etc/
- Plano para o seu aplicativo a ser instalado em um dos três locais: /usr/local/, /opt/appnameou /home/username/appname.
- Os blobs devem ser armazenados ao lado de outros arquivos de configuração, caso sejam alterados. Geralmente, é preferível usar um formato editável pelo usuário; portanto, é preferível algo como SQLite ou Berkeley DB (já que existem ferramentas de linha de comando para cada um), mas não é obrigatório.
No Windows, seus aplicativos só devem escrever no diretório Usuário. O local padronizado para arquivos de dados é Users\User\AppData. Em nenhum outro lugar parece aceitável.
No Mac OS X, as configurações do seu aplicativo devem ser armazenadas ~/Library/Preferencesjunto com todos os arquivos plist dos outros aplicativos. plistparece ser o formato preferido, mas convém verificar com as diretrizes da Apple.

E qual é a melhor maneira portátil?

Não há "melhor", para ser honesto. Existem apenas limitações e expectativas específicas da plataforma. Minha recomendação é seguir os meios específicos da plataforma, mesmo que isso signifique escrever mais código.

— desvanecer-se
fonte

1

Acho que a Microsoft desencoraja o uso do registro há alguns anos - o que é bom. Escrever no AppData, como você mencionou, é o caminho a percorrer. No .NET (talvez também na API do Windows?), Existe até um método que retorna o caminho correto.

— MetalMikester

Há também uma variável de ambiente: %APPDATA%

— greyfade 10/10/10

@MetalMikester - sim, absolutamente no local. O AppData também é suportado pelo Roaming Profile para um ambiente de domínio.

— JBRWilkinson

configurações! = config

— Yousha Aleayoub

> In my opinion, the registry was a poorly-devised system, and instead a simple text file in the Users\Username\AppData directory should be preferred.

@greyfade - O desenvolvedor de longa data da API do Windows, Raymond Chen, aborda isso e explica por que o uso de arquivos de texto no registro não é um padrão de design melhor: Por que os arquivos INI são preteridos em favor do registro

— Mick

8

No Windows, use %APPDATA%\appname. Em * NIX, use ~/.appname. Não use nomes de diretórios fixos em nenhuma das plataformas, pois o diretório inicial do usuário pode ser diferente do padrão (pode estar na rede, por exemplo).

Quanto ao formato, use o que achar melhor. Essa é uma decisão que somente você pode tomar no contexto de seu aplicativo. É desnecessário e, de fato, desaconselhável, ter uma maneira "padrão" de fazê-lo, se essa maneira "padrão" não for a melhor para o seu programa em particular.

Por exemplo, XML / JSON pode ser uma boa maneira de armazenar dados / configuração do usuário se seu aplicativo já usa XML / JSON para outra coisa. Mas se é um arquivo de configuração simples, por que adicionar inchaço ao seu aplicativo introduzindo uma dependência? Nesse caso, provavelmente é melhor usar apenas um arquivo de texto simples com var: value\nlinhas.

EDIT: Não existe uma "melhor" maneira portátil, pois os sistemas operacionais usam convenções muito diferentes para isso. Não quebre os padrões do sistema operacional sem uma boa razão.

EDIT2: Se você estiver fazendo uma configuração em todo o sistema /etcou HKEY_LOCAL_MACHINE, pergunte-se se a configuração é realmente global. Aguarde 5 minutos e pergunte a si mesmo novamente. Se a resposta ainda for afirmativa, faça um ajuste global. Lembre-se de que um usuário normal não tem acesso de gravação /etcou, HKEY_LOCAL_MACHINEao fazer isso, garante que alguém sem direitos de administrador não possa instalar seu aplicativo.

— Chinmay Kanchi
fonte

O primeiro parágrafo permite que você use Path.Combine ou algo semelhante e, assim, defina o local da raiz relativa uma vez para% APPDATA% ou ~ e deixe o código fazer o resto, para EDIT2, de fato, não existe uma solução de plataforma cruzada que eu conheça do. Talvez existam pessoas que têm escrito uma biblioteca de configuração multi-plataforma para o efeito, pelo menos seria uma boa idéia ...

— Tamara Wijsman

1

@ TomWij: Certamente qualquer desenvolvedor competente deve ser capaz de descobrir que você não precisa usar literais em todos os lugares;). É para isso que servem as variáveis.

— Chinmay Kanchi

1

~/.config/applicatonestá se tornando cada vez mais o local preferido no * nix.

— greyfade

@greyfade: Eu nunca percebi isso, mas você está certo. Na minha máquina, cerca de um quarto dos aplicativos que armazenam dados de configuração o ~fazem ~/.config/appname.

— Chinmay Kanchi

Um monte de aplicativos usa ~ / .appname no Windows (o que equivale ao diretório do seu perfil de usuário, NÃO aos documentos) e é muito irritante. Essas pastas não se escondem!

— Alan Pearce

3

Eu tento e manter fora do registro, é muito usado. Eu gostaria que todos o fizessem.

Eu gosto de manter arquivos de configuração xml ou um arquivo bin ou, ocasionalmente, um banco de dados local (SQLite).

— µBio
fonte

+1 por manter fora do registro. Não consigo encontrá-lo agora, mas me lembro de ter lido que alguém da MS havia admitido que o registro era um erro.

— Chinmay Kanchi

1

Concordo com você, exceto a parte XML. Eu usaria ini (ou arquivo de texto simples) para requisito de configuração simples e SQLite para aplicativos complexos.

— Codism

Eles estão agora admitindo isso? Eu poderia ter lhe dito isso em 1995! O Mac OS Classic acertou: Uma pasta Preferências para fornecer um local centralizado para armazenar informações de configuração, com cada aplicativo sendo salvo em seu próprio arquivo. Quando vi o Registro pela primeira vez, fiquei tipo: "A Microsoft nunca ouviu falar em não colocar todos os seus ovos em uma cesta?!?"

— Mason Wheeler

1

Eu acho que como um lugar para colocar as configurações do sistema operacional (como registro de extensão de arquivo, etc.), tudo bem. Mas se a Microsoft o publicasse como uma API somente leitura, eles provavelmente teriam sido processados por isso e precisariam torná-lo gravável de qualquer maneira.

— µBio

@Chinmay, @Mason, o registro NÃO é um erro, porque o registro FAR mais do que apenas armazena dados de configuração (consulte: política de grupo, domínios, replicação). O erro é como a Microsoft apresentou aos desenvolvedores e a falta de um bom padrão de como usá-lo. Acabou sendo um depósito de dados de aplicativos, que não é para o que sempre foi destinado.

— Matt Olenik

3

Minha resposta é uma combinação de de Chinmay Kanchi resposta e de BioBuckyBall resposta .

XML / Json para configurações simples, SQLite para configurações maiores e complexas estacionadas na pasta de aplicativo padrão do SO ou na pasta de usuário padrão do SO quando as configurações dependem do usuário. Ambos podem ser usados.

— Maniero
fonte

2

No Windows, eu manteria a configuração do aplicativo na AppDatapasta

— Graviton
fonte

1

As configurações do usuário geralmente estão em

/home/<user>/.<application>

Por exemplo, para as configurações do irssi, são /home//.irssi/config

— Chris
fonte

Mas esta é uma convenção Unix. E o Windows? E no Linux, não inunda o diretório inicial do usuário com subdiretórios? Por que não /home/<user>/etc/application?

— usar o seguinte comando

@ Lorenzo: Inundar o diretório inicial do usuário raramente é um problema.

— Chinmay Kanchi

1

Cada vez mais, as configurações estão sendo movidas ~/.config/applicationpara ajudar a manter as coisas consolidadas. Estou inclinado a concordar com esse movimento.

— greyfade

1

@ Lorenzo: Isso é exatamente o mesmo que a convenção do Windows de armazenar arquivos de configuração AppData.

— greyfade

1

@ Chris: de jeito nenhum! :-)

— Wizard79

1

Eu acho que é melhor usar o mecanismo específico da plataforma preferido. Por exemplo, no OS X, o mecanismo preferido é colocar uma lista de propriedades em ~ / Library / Preferences, e a API Cocoa possui uma interface realmente simples para armazenar e recuperar configurações a partir daí.

Se o seu aplicativo for multiplataforma, você poderá abstraí-lo com uma classe ou outros enfeites.

— mipadi
fonte

0

A única coisa que escrevo no registro é a localização do aplicativo, para que os instaladores e atualizadores possam encontrá-lo facilmente. Todo o resto é armazenado em arquivos em / AppData / Company / App

— GrandmasterB
fonte

-2

Para aplicativos Java, acho que o gson é uma boa escolha. Crie seus objetos de configuração e use o gson para convertê-los em JSON e vice-versa. Tem a vantagem de ser legível por humanos em vez de um blob serializado.

Edit: ok, então talvez não seja tão geral ...

— FeatureCreep
fonte

-2

Se você estiver escrevendo no .NET, poderá usar System.Environment.SpecialFolders para descobrir quais locais de pasta você pode usar para salvar a configuração ou mesmo alguns dados.

— James
fonte