Como devo armazenar dados somente leitura para implantar com meu aplicativo?

17

Estou desenvolvendo um aplicativo de desktop, e esse aplicativo requer algumas informações para ser executado, mas não altera nenhuma delas (os dados devem ser carregados em todas as execuções do aplicativo, mas os dados nunca são alterados). Os dados devem ser armazenados no mesmo computador em que o aplicativo está sendo executado (armazenamento do lado do cliente?).

Também é melhor se o usuário não puder alterar facilmente essas informações (suponha que ele não tenha muito conhecimento em TI).

Como devo armazenar esse tipo de informação? Um banco de dados local? XML enviado com o aplicativo?

Estou usando o WPF.

c# design data wpf

— appa yip yip
fonte

2

Isso não é uma meta. Uma meta é um site para discutir problemas ou preocupações sobre os principais sites em que as perguntas são feitas.

— jpmc26

1

Por que você não deseja que os usuários alterem as informações? Isso é uma preocupação de segurança ou o quê? Essas informações devem ser mantidas em segredo do usuário? As razões podem mudar bastante as respostas apropriadas.

— jpmc26

1

@ jpmc26 Bem, é um tipo de preocupação de segurança, mas não é grande coisa. O principal objetivo do aplicativo é se comunicar através de uma porta serial com um controlador de temperatura (como este ), e o XML armazenará algumas informações sobre os endereços de memória do controlador. Se o usuário alterá-lo, isso pode causar problemas durante a execução, então eu gostaria de evitá-lo. Mas é apenas uma preocupação, como eu disse, não é grande coisa. ps: editou a pergunta para substituir o meta pelo SE . Obrigado.

— Appa yip yip

2

Se você deseja um banco de dados local, dê uma olhada no SQLite. (Mas se os dados é pequeno o suficiente para carregar na memória RAM durante a inicialização, eu prefiro um simples estruturado arquivo como JSON ou algo binário)

— CodesInChaos

1

"Se o usuário alterá-lo, isso pode causar problemas durante a execução, então eu gostaria de evitá-lo." não soa como uma preocupação de segurança. Uma preocupação de segurança é aquela em que você tem uma senha ou similar no arquivo. Basta colocar as configurações em um arquivo XML ao lado do executável e colocar um comentário na parte superior que diz "Não toque nas configurações deste arquivo !!". Se o usuário estiver editando arquivos aleatórios no diretório de instalação, eles merecem qualquer falha que receberem.

— 21816 Roger Lipscombe

14

Um arquivo binário seria a resposta óbvia, mas depende de como você o está carregando - você também pode facilitar a vida, se puder.

O XML pode ser uma boa opção, pois há métodos incorporados em C # para ler isso. Você pode adicionar uma soma de verificação aos seus dados, para que, se o usuário alterá-la, a soma de verificação não corresponderá mais (é necessário adicionar uma verificação para garantir que a soma de verificação é válida)

Um banco de dados local pode criar mais problemas porque você tem outras dependências para poder acessá-lo

— Matt Wilko
fonte

Não pensei na soma de verificação, é uma ideia muito boa. Então, eu gere uma soma de verificação e a armazeno no meu aplicativo, para que cada vez que desserialize o XML, gere uma nova soma de verificação e a compare com a primeira?

— Appa yip yip

4

Se você armazenar a soma de verificação no aplicativo, nunca permitirá uma configuração diferente; portanto, você também poderá armazenar os dados de configuração como constantes do aplicativo no seu código. Se você quiser alterar a configuração no futuro, adicione a soma de verificação (um termo melhor seria um "hash") como um campo do XML e use-o para verificar se o XML não foi violado. Obviamente, um invasor determinado pode pesquisar seu código, encontrar sua lógica de hash e usá-lo para produzir arquivos XML válidos, mas de qualquer maneira os aplicativos do lado do cliente sempre estão vulneráveis a determinados invasores.

— SJuan76

4

Em vez de arquivo ou banco de dados local, o arquivo de recurso incorporado ao assembly seria melhor. Escondido do usuário final, facilmente gerenciável pelo desenvolvedor e ainda fácil de usar. Se o desempenho é uma preocupação, a serialização binária seria superior.

— PTwr

@ SJuan76 Sim, o problema do hash no XML é que ele pode ser alterado se alguém o desserializar. De qualquer forma, se a alteração do XML (que eu acho que não vai acontecer, mas quem sabe) só será alterada em uma nova versão do aplicativo, então acho que vou ficar com o código hash.

— Appa yip yip

2

@schmaedeck: arquivos de recursos são literalmente arquivos dentro do binário executável. Ícones e seqüências de caracteres e quaisquer outros dados constantes que seu programa precise.

— Mooing Duck

21

Se os dados nunca mudarem e forem somente leitura , basta colocá-los em um arquivo de código como uma lista de constantes.

public readonly string AppStartUpData = "MyAppNeedsThis";

Se esses dados forem diferentes por implantação, um arquivo externo será bom.

.Net vem com arquivos .config integrados (App.Config). Deve-se usá-las, pois existem maneiras padrão (integradas à estrutura) para ler as informações a partir delas.

Use os arquivos de configuração caso uma configuração precise ser alterada (nunca diga nunca), pois são apenas arquivos de texto (Xml). Se houver informações confidenciais, é possível criptografar uma configuração, se necessário.

— Jon Raynor
fonte

Pensei nas constantes / readonlys, o problema é que existem muitos dados, então acho que vou acompanhar o arquivo externo. Obrigado!

— Appa yip yip

5

@schmaedeck ... então? Você pode colocar essas definições em um arquivo separado e importá-lo. Na verdade, eu acredito que o Qt faz esse tipo de coisa ao compilar formulários e outras coisas, para que você acabe com arquivos gerados automaticamente que tenham megabytes de dados binários (por exemplo, imagens) em algumas constantes, mas se estiver em um arquivo separado, não há nada de errado nisso. .

— Bakuriu

15

Você sempre pode adicionar um arquivo ao seu projeto e definir seu tipo de construção para Embedded Resourceque seja incorporado diretamente no próprio aplicativo.

Como alternativa, um arquivo criptografado e colocado em um local acessível.

— TheLethalCoder
fonte

1

Esta é a melhor resposta. Eu gostaria de ver mais algumas orientações sobre como alcançá-lo. Você obtém os benefícios de um arquivo de configuração potencialmente alterável, mas o mantém estático à medida que é incorporado ao seu assembly.

— Gusdor 21/07

5

Se você não quiser nem mesmo espiar os dados, serialize-os em um arquivo de dados binários.

Somente o aplicativo saberia o tamanho dos pedaços para ler.

Eu não sei c #, mas em Java você criaria o arquivo assim:

FileOutputStream fos = new FileOutputStream(file);      
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(var1);
oos.writeObject(var2);
oos.writeObject(var3);
oos.writeObject(var4);

... e eles lêem assim:

FileInputStream fis = new FileInputStream(file);
ObjectInputStream ois = new ObjectInputStream(fis);
Object o[] = new Object[4];
o[0] = ois.readObject();
o[1] = ois.readObject();
o[2] = ois.readObject();
o[3] = ois.readObject();

— Tulains Córdova
fonte

Certamente vou usar a serialização binária. Muito obrigado pelo seu tempo!

— Appa yip yip