java - programacion - ¿Cuál es la mejor manera de gestionar los datos de configuración?

manual de programacion android pdf

Question

Estoy trabajando en un paquete de productos que tiene 4 productos. En este momento, todos los datos de configuración se encuentran en los archivos XML o de propiedades. Este enfoque no se puede mantener, ya que tenemos que administrar diferentes archivos de configuración para diferentes entornos (por ejemplo, Producción, Desarrollo, etc.)

Entonces, ¿cuál es la mejor manera de manejar los datos de configuración?

Además, ¿podemos modularizar esto en un módulo separado? Para que todos los productos puedan utilizar este módulo. No queremos usar los archivos de propiedades. Estoy buscando una solución en la que podamos mover todo el código de configuración específica como un nuevo módulo de configuración y conservar todos los datos de configuración en la base de datos.

Answer 1

Al utilizar commons-configuration , tiene una API unificada para acceder a las propiedades, sin importar cómo estén representadas: .properties, xml, JNDI, etc. Por ejemplo:

config.properties :

jdbcHost=192.168.12.35
jdbcUsername=dbuser
jdbcPassword=pass

config.xml :

<config>
<jdbcHost>192.168.12.35</jdbcHost>
<jdbcUsername>dbuser</jdbcUsername>
<jdbcPassword>pass</jdbcPassword>
</config>

En ambos casos serán accesibles con algo como:

String host = config.getString("jdbcHost");

Answer 2

Aquí hay una solución estúpida simple.

El fragmento de código, que intenta utilizar primero el archivo de propiedades en el directorio actual. Si falla, use el archivo de propiedades en el directorio de recursos (o en el archivo jar) en su lugar.

 Properties configFile = new Properties();
try {
configFile.load(new FileInputStream("production.properties"));
} catch (Exception e) {
System.err.println("Can not read properties, try to use default properties file.");
configFile.load(this.getClass().getClassLoader().
getResourceAsStream("development.properties"));
}

Answer 3

Hay muchas estrategias diferentes. Todos ellos son buenos y dependen de lo que más le convenga.

1. Construye un único artefacto y despliega configuraciones en una ubicación separada. El artefacto podría tener variables de marcador de posición y, en el despliegue, se podría leer la configuración. Eche un vistazo al marcador de posición de la propiedad Springs. Funciona fantásticamente para aplicaciones web que usan Spring y no implica involucrar a las operaciones.
2. Tener una configuración de propiedad externalizada que vive fuera de la aplicación web. Mantener la ubicación constante y leer siempre desde la configuración de la propiedad. Actualice la configuración en cualquier etapa y reinicie los nuevos valores.
3. Si está modificando el entorno (es decir, el servidor de aplicaciones que se está utilizando o los permisos de usuario / grupo) considere el uso de los métodos anteriores con títere o chef. También eche un vistazo a la gestión de sus archivos de configuración con estas herramientas.

Answer 4

Las variables de entorno son casi la forma más fácil de ir. System.getenv("...") como lo haría en cualquier otro momento, acceda a ellos con System.getenv("...")

Answer 5

Para todos nuestros entornos, los datos de configuración se encuentran en las máquinas de destino en forma de archivos de propiedades. Usamos PropertyPlaceholderconfigurer de SpringFramework para enlazar estas propiedades con nuestras aplicaciones para mantener las cosas portátiles en todos los entornos.

Por ejemplo, siempre que sepa que /etc/myapp/database.properties estará presente en la máquina en la que se ejecutará mi aplicación, entonces, en mi configuración de Spring, solo necesito algo así:

 <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>/etc/myapp/database.properties</value>
</list>
</property>
</bean>
<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url"
value="jdbc:mysql://${db.host}:3306/${db.name}" />
<property name="username" value="${db.user}" />
<property name="password" value="${db.pass}" />
</bean>

Hay muchas opciones para esa clase de Spring sobre dónde pueden vivir los archivos de propiedades. Incluso puedes hacer sustituciones y pasarlas como variables de entorno:

 <bean id="myPropertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="searchSystemEnvironment" value="true" />
<property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
<property name="locations">
<list>
<value>${database.configuration.file.url}</value>
</list>
</property>
</bean>

Y en bash_profile (o lo que sea): export JAVA_OPTS = "-Ddatabase.configuration.file.url = file: ///etc/myapp/database.properties"

O simplemente la misma opción -D pasada cuando llamas "java" dependiendo de lo que estés haciendo.

FWIW, mantenemos nuestros archivos de propiedades por separado como RPM.

Answer 6

Si sus aplicaciones funcionan con una base de datos, puede crear una tabla de "configuración" de la siguiente manera:

create table configuration (mode char(3), key varchar(255), value varchar(1023));

Lo inicializaría utilizando un script de inicio, digamos init.sql con contenido en la línea de:

insert into configuration values (''pro'', ''param1'', ''value1''); -- production
insert into configuration values (''dev'', ''param1'', ''value1''); -- development
insert into configuration values (''tst'', ''param1'', ''value1''); -- testing
...

Los beneficios de este enfoque son los siguientes:

• versionas el script junto con tu código
• puede extenderlo fácilmente para incluir configuraciones por usuario o por grupo agregando una identificación de usuario / grupo
• puede cambiar la configuración en tiempo de ejecución si necesita hacerlo
• puede usar la misma pila (JPA + DAO, Cayenne ...) que normalmente usa para manejar los datos de la aplicación central para manejar los datos de configuración

Answer 7

Ya casi está ahí ... mantendría su mismo enfoque y obtendría el archivo de configuración correcto para la instancia de la aplicación que se ejecuta mediante un método similar a cualquiera de los siguientes:

1. Asigne un nombre diferente a todos los archivos de configuración y haga que su aplicación los incorpore según algunos criterios únicos (nombre de usuario, nombre de host, etc.):

   • producción .propiedades
   • desarrollador1 .propiedades
   • desarrollador2 .propiedades

2. Manténgalos fuera del código base en una ubicación basada en una variable de entorno que la aplicación asume que existe:

   • YOURAPP_CONFIG_DIR /server_config.xml
   • YOURAPP_CONFIG_DIR /database_config.properties

Incluso he usado una combinación de estos enfoques en el mismo proyecto (# 1 para configuraciones de procesos de compilación y # 2 para configuraciones de tiempo de ejecución).

Answer 8

Config es una herramienta de gestión de archivos de configuración. Puede crear una configuración que sea común en todos los entornos, o puede crear una configuración específica del entorno. Puede seguir utilizando sus archivos XML y de propiedades, y dejar que Config mantenga las diferencias en el entorno. Puede pensar en Config como su base de datos centralizada y puede generar el archivo de configuración en el formato que desee. Siempre que desee su archivo de configuración, simplemente implemente (presione o tire) desde Config hasta la ubicación deseada. Tenga en cuenta que soy parte del equipo de Config.