Configuração de tempo de compilação: programática ou baseada em arquivo?

Question

Configuração de tempo de compilação: programática ou baseada em arquivo?

#1 resposta do (1 votos)
#2 resposta do (0 votos)
#3 resposta do (0 votos)
#4 resposta do (-1 votos)

5

Precisamos personalizar um aplicativo de desktop em tempo de compilação. Os usuários não podem alterar a configuração. Somente desenvolvedores e gerentes de lançamento podem fazer isso.

A configuração é um pouco complexa. Existem mais de 10 módulos. Cada módulo precisa de configuração, incluindo valores, sinalizadores de capacidade, etc. Temos 5 grupos de configuração chamados perfis.

Agora, vou escolher uma das duas opções. A primeira é a abordagem programática. Podemos criar interfaces de configuração para cada módulo e implementá-las para cada perfil. A alternativa é que usando arquivos de configuração. Eu gosto de abordagem programática devido a sua flexibilidade (por exemplo, podemos herdar um perfil de outro). Além disso, ele fornece verificação de tempo de compilação. Mas arquivos de configuração (como XMLs) são fáceis de manter e entender.

Talvez, uma abordagem mista seja a melhor. Mas não sei como fazer isso. Você tem alguma ideia?

Obrigado.

release-management configuration

por Q Q 28.04.2016 / 16:21

fonte

4 respostas

Tags release-management configuration

Use a propriedade de valor do dicionário como a chave do dicionário Gerenciando configurações de liberação ao usar o TFS Build

score 1 · Answer 1

O grande benefício de um arquivo de configuração, seja xml, json, ini, é que ele separa os dados do comportamento. Isso pode ajudar a mantê-lo legível. Você pode fazer isso com código também; você simplesmente não é forçado a fazer isso.

Se você preferir ficar com os arquivos de configuração, uma forma de atender sua necessidade de proteger sua configuração seria compilar sua configuração de alguma forma. Isso poderia ser qualquer coisa, desde a ofuscação à criptografia, passando pela proteção contra zip e senha. Nenhuma será perfeitamente segura; nem é código, mas deve evitar que o usuário casual mexa nas configurações.

A configuração no código pode ser mantida simples, mas requer disciplina. Os padrões de construção ou criação podem ser aproveitados para isso. Se você tiver tempo para escrever um, você pode ir tão longe quanto criar um construtor DSL (Domain Specific Language).

score 0 · Answer 2

Eu tenho uma ideia para abordagem mista. Podemos gerar classes de configuração a partir dos arquivos de configuração. Eu imagino esse mecanismo: Cada módulo tem um esquema xsd para sua configuração necessária. Quando o esquema é alterado, a classe de configuração será regenerada automaticamente. Assim, outras classes usarão a configuração de forma programática.

Os perfis terão arquivos de configuração xml para cada módulo. XMLs podem ser validados contra XSDs. No aplicativo principal, um gerenciador de perfil carregará xmls de configuração e passará a eles seus módulos. Assim, a configuração poderia ser mantida facilmente com XMLs.

score 0 · Answer 3

Abordagem do arquivo de configuração puro que permite herança:

Como você deseja ter um conjunto de configurações pai que possa ser herdado, você poderia configurar um sistema de arquivos de configuração em duas camadas? Tenha um arquivo "master" e um "específico", e se o master e o específico definirem o mesmo valor de configuração, o valor do arquivo específico será usado.

Esta não é uma idéia nova - pense no css, na configuração principal do apache e no .htaccess, e tenho certeza de muitas outras tecnologias também.

Uma ligeira variação disso que você vê com os arquivos de configuração do git e qualquer arquivo de configuração baseado no bash é a idéia de "terceirizar" outro arquivo (incluindo ele como herança) - No início de um arquivo, você indica que estende outro, e quando seu arquivo está sendo lido, a instrução "estenda tal e tal arquivo" significa "pare de ler este arquivo, processe todos os arquivos, e continue lendo este arquivo".

Isso permite que você tenha vários níveis de herança.

score -1 · Answer 4

Aqui está outra abordagem mista.

Gostaria de perguntar o que muitas vezes muda. Esses valores podem ser colocados em um excel ou em uma planilha como um arquivo. Esse campo terá rótulos, unidades e intervalos válidos para cada valor editável.

O que não é frequentemente alterado pode entrar no código. Isso pode entrar em uso em classes de ambiente. As classes permitem que os casos de uso sejam executados, mas o take é para um ambiente no qual o sistema poderia estar. Ele irá atualizar os objetos necessários (aqui está o ambiente da suposição do sistema). Então, valores de retorno e parâmetros são passados para métodos. A classe não deve ter nenhum ifs ou loops.