El diseño multi-nivel de aplicación a la barra de progreso uso

Question

Tengo una aplicación de nivel múltiple en C # que se supone que realizar tareas en una base de datos (Si uso por primera vez, podemos crear la base de datos y llenarlo con algunos datos). Cuando inicialmente diseñado la aplicación que no cuenta para un posible control de barra de progreso, por no hablar de cualquier información sobre el progreso de cualquier tipo. ¿Cómo puedo modificar el diseño de la aplicación para poder informar de las operaciones de base de datos avanzan a la capa de interfaz de usuario? ¿Hay una solución por ahí que es reutilizable y no me obligan a modificar todos mis funciones para tomar entradas adicionales para la presentación de informes?

Answer 1

No. Dependiendo de qué tan grande es su aplicación es, usted tiene mucho trabajo por delante.

Para los informes de progreso de trabajo, necesita el código que está llevando a cabo el trabajo a los acontecimientos plantean cuando una unidad de trabajo se haya completado. Que las necesidades de eventos que se manejan en los indicadores de la capa de interfaz de usuario y progreso actualizados.

Un buen punto de partida sería la de ver en el uso BackgroundWorker (hay un ejemplo en MSDN aquí - http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx ). Una vez que esté familiarizado con el BackgroundWorker usted debe estar en una mejor posición para decidir qué cambios necesita hacer para su aplicación.

Answer 2

Como Greg dijo, hay una gran cantidad de trabajo por delante. Sin embargo, hay muchas maneras de abordar el problema, y ??la mejor para usted depende de qué información contextual pasa hacia abajo desde el cliente a las capas de aplicación / base de datos ya. Por ejemplo, si un identificador de ficha o transacción sesión se pasa desde el cliente a la aplicación en el curso normal de la ejecución de una consulta / transacción o una referencia del reconocimiento pasa de nuevo de forma asincrónica de la aplicación al cliente, a continuación, para las consultas / transacciones para las que los informes de progreso era necesario actualizar usted podría tener la aplicación de una tabla de estado que el cliente pueda consultar. Esto podría reducir la cantidad de re-trabajo requerido. Básicamente, es necesario tener en cuenta el "middleware" en el lugar ya y ver si alguno de los que se puede aprovechar para correlacionar las transacciones entre niveles.

Answer 3

Se podría modificar el código del servidor para que se actualice la información de progreso en el extremo del servidor (sin cambiar las firmas de función), y luego tener un método independiente que se puede consultar esta información por separado.

Esto le permite al apoyo de adaptación para el progreso sin tener ningún impacto en absoluto sobre sus llamadas existentes en el servidor, basta con añadir un nuevo hilo de fondo en la comprobación de la interfaz de usuario para la información de progreso actualizado, mientras que una tarea larga duración está en marcha.

Edit: Creo que el mismo enfoque podría funcionar para las tareas que se realizan en el cliente. Pero aún así, una clase estática indicador de progreso podría ser utilizado también en este caso.