Fichero de configuracion para libreria de clases

18/11/2003 - 10:28 por Mario Barro | Informe spam
Hola a todos/as;

En una librería de clases (*.dll) cual sería el mecanismo para guardar
parámetros varios que puedan ser manipulados sin recompilar la librería.

Los ficheros de configuración son buena opción, pero cuando existe un
ejecutable, no?
aplicacion.exe.config

· Existe algo así para las librerias de clase?

· Había barajado utiliazar un documento xml para ello, a falta de algo más
rápido como lo mencionado anteriormente. Sugerencias?


Saludos

Preguntas similare

Leer las respuestas

#1 Alejandro Mezcua
18/11/2003 - 13:38 | Informe spam
Hola, Mario.

La librería por si sóla no hace nada, necesitas cargarla ya sea desde un
ejecutable tuyo o desde IIS por ejemplo si trabajas con ASP.NET. Para esos
dos tipos de ejecutable cuentas con archivos de configuración.

De todas formas, no es muy recomendable hacer depender a una dll de un
archivo de configuración concreto. Dado que una dll está diseñada para ser
utilizada desde otro sitio (incluso desde otra dll), debería ser flexible
con la forma en la que recibe datos de configuración. Puedes pasarle cadenas
de texto, o elementos XmlElement que contengan los datos necesarios para su
configuración (por ejemplo cadenas de conexión a BBDD).

Un saludo,

Alejandro Mezcua
MVP .NET
Zaltor Soluciones Informáticas

"Mario Barro" wrote in message
news:
Hola a todos/as;

En una librería de clases (*.dll) cual sería el mecanismo para guardar
parámetros varios que puedan ser manipulados sin recompilar la librería.

Los ficheros de configuración son buena opción, pero cuando existe un
ejecutable, no?
aplicacion.exe.config

· Existe algo así para las librerias de clase?

· Había barajado utiliazar un documento xml para ello, a falta de algo más
rápido como lo mencionado anteriormente. Sugerencias?


Saludos


Respuesta Responder a este mensaje
#2 Mario Barro
18/11/2003 - 14:58 | Informe spam
Hola de nuevo;

Voy a exponer brevemente el desarrollo, ya que así, espero se entienda mejor
la idea perseguida:

Se trata de un servicio para Windows sobre una arquitectura de varias capas
englobado en un mismo proyecto.

· Servicio Windows --> *.exe
· MonitorServicio ( Net. Remoting como servidor para interactuar y
monitorizar el servicio de forma gráfica ) --> *.dll
· BusinesRules ( Lógica de proceso ) --> *.dll
· Global ( Definición de entidades globales al proyecto, tipos enumerados
públicos, etc) --> *.dll
· SocketServer ( Servidor asíncrono como principal función del
yecto ) --> *.dll
· DataAcess ( Encapsulación acceso a bbdd Sql-Server) --> *.dll
. BBDD -SQL-Server ( Lógica en procedimientos almacenados) -->
Transact-SQL

Y El caso es que quería generar una especie de fichero común al proyecto
*.ini (de los antiguos) para los parámetros comunes al proyecto.
Léase: coenxiones bbdd, credenciales, parámetros varios de inicio, etc

Desde este fenfoque el único *.exe es el propio servicio para añadir un
"config" pero la idea era abstraer al mismo de toda la capa de abajo.
Qué me recomendáis como enfoque una vez expuesto.

De nuevo mil gracias por vuestra inestimable ayuda.
Saludos cordiales
Mario Barro
Respuesta Responder a este mensaje
#3 Alejandro Mezcua
18/11/2003 - 16:21 | Informe spam
Hola de nuevo Mario.

Yo insisto en que los componentes que deben abstraerse de detalles de
archivos son las dll's. Quizá lo veas mejor si 'pintas' las capas en el
orden inverso al que las has puesto, es decir, el servicio windows es la
capa inferior.

De hecho, como verás en la consola de configuración de servicios de Windows
(MMC) es al servicio (al ejecutable) al que se le pueden pasar parámetros
por línea de comandos. Y si piensas en como se configuran servicios, casi
todos se gestionan en base a aplicaciones independientes que se incluyen en
el panel de control y que únicamente escriben valores en el registro o crean
archivos de configuración generales muy bien localizados en el disco. Cuando
se quieren aplicar los cambios a un servicio, o bien se reinicia el proceso,
o bien se le manda alguna señal (sockets, archivo, remoting como en tu caso,
etc) que hace que recargue sus parámetros de configuración, pero normalmente
quien lo hace es la capa más baja, es decir, el ejecutable.

Esto no quiere decir que lo tenags que hacer así, ni mucho menos, pero suele
ser más cómodo a la hora de, por ejemplo, llevarte la aplicación a otro
equipo, ya que sólo has de controlar un archivo común (que no tiene por qué
ser .config).

Puedes optar como dices por disponer de varios archivos de configuración,
uno por cada capa y que cada capa busque el suyo, pero me parece que lo
único que se conseguiría sería complicar un poco la distribución de la
aplicación (aunque no excesivamente tampoco).

Un saludo,

Alejandro Mezcua
MVP .NET
Zaltor Soluciones Informáticas

"Mario Barro" wrote in message
news:
Hola de nuevo;

Voy a exponer brevemente el desarrollo, ya que así, espero se entienda


mejor
la idea perseguida:

Se trata de un servicio para Windows sobre una arquitectura de varias


capas
englobado en un mismo proyecto.

· Servicio Windows --> *.exe
· MonitorServicio ( Net. Remoting como servidor para interactuar y
monitorizar el servicio de forma gráfica ) --> *.dll
· BusinesRules ( Lógica de proceso ) --> *.dll
· Global ( Definición de entidades globales al proyecto, tipos enumerados
públicos, etc) --> *.dll
· SocketServer ( Servidor asíncrono como principal función del
yecto ) --> *.dll
· DataAcess ( Encapsulación acceso a bbdd Sql-Server) --> *.dll
. BBDD -SQL-Server ( Lógica en procedimientos almacenados) -->
Transact-SQL

Y El caso es que quería generar una especie de fichero común al proyecto
*.ini (de los antiguos) para los parámetros comunes al proyecto.
Léase: coenxiones bbdd, credenciales, parámetros varios de inicio, etc

Desde este fenfoque el único *.exe es el propio servicio para añadir un
"config" pero la idea era abstraer al mismo de toda la capa de abajo.
Qué me recomendáis como enfoque una vez expuesto.

De nuevo mil gracias por vuestra inestimable ayuda.
Saludos cordiales
Mario Barro


Respuesta Responder a este mensaje
#4 Mario Barro
18/11/2003 - 19:09 | Informe spam
Gracias Alejandro por tu atención y tu tiempo (que hoy día es caro).

Como bien dices, había planteado unos archvivos de configuración por capa.
En principio la distribución de la aplicación no va ser lo más usual en este
caso en concreto ya que es un desarrollo muy focalizado.

Y la idea era independizar en este contexto lo más posible las distintas
capas y que no fuese necesario
detener el servicio para poder modificar parámetros de los distintos niveles
llegado el caso.

Estudiaré tu propuesta detenidamente , que por otro lado tiene toda su
lógica también.

Saludos y gracias de nuevo.
Mario Barro
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida