En caso de una aplicación de C # interno se compila con la lógica de negocio?

Question

[fondo]

Por lo tanto, tengo una aplicación C # que fue escrito antes de llegar aquí. No estoy en el organigrama dev, en este momento, pero yo soy el plomo tecnología en mi subgrupo dentro del organigrama de marketing en Internet. Mi responsabilidad es la automatización de procesos, un apoyo mínimo de escritorio y aplicaciones personalizadas que hacen nuestra vida más fácil.

[/ fondo]

[detalles de la aplicación]

Tenemos una aplicación que crea un archivo de base de datos personalizada de una lista de direcciones URL. Fue diseñado para tener un archivo de entrada, y dos archivos de salida para las dos aplicaciones que utilizan este tipo de archivos db. La regla de la diferencia entre los dos archivos de salida se compila en el código.

[detalles / app]

Si una aplicación C # interno se compila con la lógica de negocio que no puede ser cambiado sin que se re-construye?

Answer 1

Las aplicaciones internas tienen un objetivo: apoyar el proceso

.

Si las reglas para la creación de la salida son simples, cambia todos los días y se ponen por un usuario, la compilación en el binario es totalmente erróneo y una inversión en una interfaz gráfica de usuario y un nuevo conjunto de programadores podrían hacer mucho bien. Si las reglas son complejas, cambiar una vez al año y están obligadas por la dirección, de haberlos compilado en el binario es una rentable forma sencilla, para su mantenimiento y evitar que los usuarios tocar el violín con la parte interna.

Como siempre, la respuesta tiene que ser "depende".

Answer 2

Si se cambia la lógica de forma regular, se debe evitar la construcción de ésta en el programa. Por otra parte, ya que es interno, supongo que el proceso requiere para reconstruir la aplicación es mínima o inexistente, por lo que no puede hacer una gran diferencia.

Answer 3

• ¿Cuánto tiempo se necesita para alterar la lógica de negocio y luego volver a compilar?
• ¿Cuánto tiempo se necesita para alterar la lógica de negocio sin tener que recompilar en la nueva versión?
• ¿Cuánto tiempo se tarda en recodificar?
• ¿Cómo afectará esto afecto en términos de horas extra gastado en el futuro?
• ¿Alguna de las personas que necesitan la aplicación incapaces de alterar la lógica de negocio, ya que es en forma de código?

Responder a estas 5 preguntas dará una respuesta.

Answer 4

Si la lógica no necesita ser cambiado, entonces sí que probablemente debería ser compilado junto con el código.

Por otro lado, si hay ciertos factores que podrían cambiar el comportamiento de esta lógica de negocio a continuación, probablemente debería proporcionar un medio de cambio que, como archivos de configuración XML que alteran su comportamiento.

Answer 5

Por supuesto, si usted sabe que la utilidad sólo será utilizada dentro de su organización y para un solo propósito que no hay nada de malo en mezclar sus reglas de negocio con la lógica. El exceso de diseño (en este caso hacer el código reutilizable cuando nunca se volverá a utilizar) no sería un uso eficiente de los recursos.

Answer 6

I suelen emplear múltiples estrategias de configuración basada en la probabilidad de cambio.

En primer lugar los no las reglas de negocio de venta con código sin documentar en algún sentido. Código tiene una gran cantidad de variables y sólo algunos de ellos se puede cambiar de forma segura mientras que todavía mantiene el comportamiento correcto. Normalmente me pongo una constante en el inicio de la clase para identificar qué comportamiento se puede cambiar, es decir,

// Prefer this
const int AllowDownloadAttempts = 2;
if (AttemptDownload() > AllowDownloadAttempts) RegisterAndAllowDownload();

// Over this
if (AttemptDownload() > 2) RegisterAndAllowDownload();

Una regla básica que sigo es otra cosa que no sea [-1, 0, 1] debe ser documentado.

Si no es crítico y no es probable que cambiar a menudo de lo que lo colocaría en el archivo de configuración de aplicaciones (por ejemplo App.config) y acceder a ella a través de una clase de configuración inflexible de tipos para que pueda realizar un seguimiento de sus usos para saber cuándo es seguro para quitar o cambiar.

Si tiene que ser cambiado con frecuencia o cambiado por los usuarios de negocios entonces yo almacenarla en una base de datos y proporcionar una interfaz gráfica de usuario simple para editarlo luego cargarla en una clase de configuración inflexible de tipos cuando se carga la aplicación.