Pregunta

Hay varios valores que he estado almacenando en las secciones de configuración de ASP.NET para cada " módulo " ;. Me he estado preguntando si incluso pertenecen a estos archivos.

El fondo se encuentra en: Estas son varias instancias de la aplicación web implementada. Todos usan la misma base de datos pero tienen sus propios ajustes.

Estoy seguro de que las diferencias entre desarrollo y producción van en los archivos de configuración. Algunos de los valores que conozco deben incluir: cadenas de conexión, proveedores a utilizar, configuración de depuración, etc.

He factorizado todas las piezas comunes de las clases con sus propias reglas y métodos. Las piezas que quedan son configuraciones misceláneas para cada módulo en cada sitio. Algunas de las opciones que no estoy seguro incluyen:

  • Para ModuleA, Mostrar / Ocultar opción
  • Para ModuleB, ¿Cuál es la terminología que se utilizará para este campo?
  • Para ModuleC, Permitir que el usuario final realice una acción X
¿Fue útil?

Solución

Mmm, esto suena a cosas que tal vez quieras cambiar en tiempo de ejecución para tu aplicación sin tener que modificar la aplicación .config. Una regla de oro que me gusta seguir es que cualquier cosa en la configuración debe ser para la implementación o la configuración del servidor. En este caso, su configuración parece estar modificando el comportamiento de la aplicación, por lo que probablemente los movería a la base de datos si no es un esfuerzo excesivo.

Otros consejos

El Módulo A y el Módulo C suenan como si fueran información del perfil del usuario. Si no son dinámicos por usuario, pero podría agregar una funcionalidad posterior, entonces puede moverlos a una base de datos.

He escrito aplicaciones donde ModuleB también se habría colocado en una base de datos. Cosas como etiquetas de formularios, etc. pueden ir fácilmente en una base de datos. Si, en una fecha posterior, alguien decide agregar o eliminar dos puntos a todas las etiquetas de formulario, es algo muy fácil de hacer si todo el texto se almacena en una base de datos.

Considere la situación cuando necesite editar uno de los valores.

Si el valor está en web.config, guardar el cambio en ese archivo causará que la aplicación se recicle, eliminando inconvenientes a los usuarios actuales. No es tanto un problema si su aplicación está en una intranet que solo se usa durante el horario comercial (aunque podría recibir una llamada enojada del tipo que se quedó hasta tarde). Pero potencialmente un problema en un sitio web público con usuarios internacionales.

Si el valor está en una base de datos, no tendrá ningún impacto en el procesamiento de la aplicación de esa manera.

De cualquier manera, considere si los valores se almacenan en caché en la memoria RAM de la aplicación (web.config es). ¿Están los valores de la base de datos en una variable de aplicación o en caché? Si es así, es posible que no sepa cuándo ocurrirá el cambio. A menos que desee reiniciar la aplicación.

¿Y qué diferentes accesos y permisos necesitarían los administradores apropiados para realizar los cambios? Alguien tendría que tener acceso a los servidores web para cambiar web.config, oa la base de datos (y la tabla) para cambiar eso.

Algunas preguntas: ¿Por qué usa la misma base de datos para varias instancias de la aplicación, y cómo afectará ese mantenimiento? En el futuro, ¿será una opción dividir la base de datos para mejorar el rendimiento? ¿El modelo de configuración es compatible con ese cambio mejor que el basado en la base de datos?

En otras palabras, tendrá que considerar muchas variables para poder responder a su pregunta :-)

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top