Arquivos INI ou registro ou arquivos pessoais?


19

Quero salvar a configuração do meu projeto, que inclui

  1. Tamanho da tela
  2. Posição da tela
  3. Caminhos da pasta
  4. Configurações de usuários e assim por diante.

Os locais padrão onde você pode salvar esses valores de configuração são:

  1. Registro
  2. Arquivos INI
  3. Arquivos pessoais (como * .cfg)

Como você escolhe entre esses lugares? Além disso, existem prós e contras no uso de algum deles?


2
Quais ferramentas você está usando? Algumas tecnologias vêm com uma construção bastante agradável nas ferramentas de gerenciamento de configuração.

@ Pierre303 atualmente usando VS 2008 para VC ++
Shirish11

Os usuários precisarão fazer alterações?
Jeffo

1
Já considerou YAML, você obtém o melhor dos dois, ini e xml en.wikipedia.org/wiki/YAML
JF Dion

Respostas:


20

Também existem prós e contras no uso de algum deles?

Registro:

  • + Relativamente padrão no ambiente Windows.
  • + Geralmente bom suporte de instaladores, etc.
  • - API específica da plataforma, se você quiser portar seu aplicativo.
  • - Não é particularmente legível por humanos.

Arquivos INI:

  • + Formato simples.
  • + Portátil.
  • + Legível por humanos.
  • - Pode ser difícil armazenar informações mais complexas (por exemplo, qualquer coisa aninhada com mais de dois níveis de profundidade).
  • ?Pode ser necessário escrever seu próprio analisador (embora não seja difícil) ou usar uma biblioteca externa como SimpleIni (obrigado a Jonathan Merlet pelo comentário).

Arquivos XML (acho que essa é a opção .cfg):

  • + Um formato padrão.
  • + Portátil.
  • + Suporta estruturas profundamente aninhadas.
  • - Não é particularmente legível por humanos.

Pessoalmente, para aplicativos Windows, costumo usar C # e acompanho um arquivo pessoal para o usuário, armazenado como XML. Eu faço isso normalmente porque a legibilidade humana geralmente não é uma prioridade nos tipos de aplicativos que eu escrevo (e o aplicativo deve ter um editor de configuração, em qualquer caso) e, no ambiente .NET , é muito fácil trabalhar com XML. Muitas vezes, acabo com um objeto UserConfiguration que simplesmente é serializado de e para um arquivo de configuração - quase nenhum desenvolvimento envolvido (análise, conversão de itens), e você tem sua configuração pronta para uso em um ambiente fortemente tipado.


Eu usei o SimpleIni para analisar arquivos INI há um tempo atrás e estava funcionando bem.
Jonathan Merlet

@ JonathanMerlet obrigado, adicionei SimpleIni ao post.
Daniel B

15

Eu iria com arquivos INI, eles são a opção mais amigável para humanos:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

O XML pode ser uma boa opção, mas não pode superar a simplicidade e a elegância do INIs:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

Os INIs também são muito bem compreendidos e independentes de plataforma. Provavelmente, não existem tantas ferramentas disponíveis para eles quanto para arquivos XML, porque, bem, quem precisa de uma ferramenta especializada para ler e editar um arquivo INI?


2
Engraçado, mas acho o XML mais bonito e fácil de ler. Para aqueles que não gostam da verbosidade, o JSON é uma alternativa adequada.
31712 Robert Harvey

3
@RobertHarvey JSON I like (e usaria se eu precisava de mais profundo de nidificação), mas XML não é realmente minha xícara de chá ...
yannis

2
O XML pode ser melhorado rolando valores em atributos. Por exemplo,<window width="600" height="350" />
Robert Harvey

Na verdade, estou surpreso que ninguém tenha mencionado o YAML ainda. Eu sinto que é um toque mais amigável ao ser humano do que o JSON, mas bastante semelhante em capacidade e sintaxe. O site yaml.org provavelmente afugenta qualquer pessoa que ainda não esteja familiarizada com ele.
Daniel B

@DanielB Alguém mencionou YAML ;)
yannis

6

Minha preferência é arquivos XML. Eles são hierárquicos, você pode dobrá-los à sua vontade de quase qualquer maneira imaginável, eles são bem compreendidos, independentes de plataforma e existe uma grande variedade de softwares disponíveis para lê-los e escrevê-los.


6
Mas horrivelmente detalhado e tende a não ser legível para o ser humano, afinal (pense não recuado ou inchado ao máximo com declarações de espaço para nome e outros bs).
precisa saber é o seguinte

1
@Manjabes: Características que dificilmente serão significativas para os arquivos de configuração.
22712 Robert Harvey

@ Robert Harvey: muito significativo onde eu moro. Para a intromissão básica nas configurações, use o gui, e nas configurações avançadas, edite o ini.
Pieter B

6

Para expandir a sugestão de Jeff D de YAML , aqui está uma breve introdução.

O YAML é semelhante ao JSON (na verdade, o JSON é um subconjunto do YAML desde a versão 1.2 do padrão YAML e, portanto, o JSON válido pode ser analisado pelos analisadores YAML). À primeira vista, a principal diferença é que o YAML (por padrão) usa recuo em vez de colchetes para mostrar a hierarquia. Também há uma notável falta de aspas para seqüências de caracteres. Um rápido exemplo de cima:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

Veja a página YAML da Wikipedia para melhores exemplos. Existe suporte para YAML para a maioria dos principais idiomas (consulte yaml.org para obter detalhes).


3

Você esqueceu uma opção: o banco de dados. Isso é usado principalmente em cenários em que os usuários efetuam login no seu aplicativo quando o aplicativo não pode confiar no usuário logado do Windows. Por exemplo, quando seu aplicativo está sendo executado em janelas no modo quiosque.


Você pode precisar de um arquivo ou chave do Registro INI para armazenar os detalhes de conexão / string para o banco de dados
Classe Skeleton

O @CamelCase Inifile ou chave de registro já foi mencionado na pergunta, mas não no banco de dados. Eu não quis dizer que você não pode usar vários métodos ao mesmo tempo.
Pieter B

1

Minha preferência pessoal são arquivos XML:

Na maioria dos casos, não espero que o usuário precise editar suas definições de configuração, para que o problema de legibilidade humana não seja um argumento nesse caso.

Se eles precisarem editá-los, você pode fornecer uma ferramenta de edição - isso evita que o usuário faça algo estúpido com os dados. Se eles quiserem restaurar as configurações padrão, basta dizer-lhes para excluir o arquivo x, o que a maioria dos usuários se sentirá à vontade.

Observe que você ainda precisa ter cuidado para ter permissão para armazenar seu arquivo, pois alguns locais não têm acesso de gravação por padrão no Windows 7 etc.


Os arquivos INI são uma boa maneira padrão de armazenar a configuração e são testados e testados, mas me parecem um pouco 'Windows 3.1'!

Provavelmente, a melhor opção se você deseja que o usuário possa mexer com seus dados


Eu pessoalmente iria me afastar do registro. Por um lado, você não pode garantir que o usuário tenha as permissões necessárias para ler / gravar onde quer que você queira armazenar seus dados.

Nos sistemas operacionais mais recentes, onde a virtualização do registro entra em ação, isso pode causar uma grande confusão, porque você não pode 'ver' as configurações virtualizadas - isso nos incomodou mais de uma vez, onde passamos horas tentando descobrir por que algo não estava funcionando.


3
Se você está preocupado com as Permissões para locais de registro, provavelmente está tentando armazená-las no lugar errado. O usuário deve ter permissões para a seção HKey_Current_User, e é aí que as configurações por usuário devem estar!
31512 Neil White

@ NeilWhite - concordou que eles deveriam ter permissões, mas um administrador de TI zeloso demais pode alterar isso (ou fornecer permissões de leitura / gravação, mas não criar). Além disso, o OP não mencionou que essas configurações eram necessariamente por usuário , elas podem ser por máquina.
amigos estão

Além disso, o registro pode ter limite de tamanho. Arquivos não.
linquize
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.