2010-07-01 35 views
6

¿es una mala idea cargar todo desde el trabajador de fondo? El código actual se ejecuta en Form_load. estamos sacando una gran cantidad de datos del servicio web. algunos trabajos de larga ejecución están en segundo plano.Trabajador de fondo C winform

¿sería una mala idea cargar todo desde el trabajador de fondo sin importar cuán pequeño o grande sea el código? cada función para ejecutar en el trabajador de fondo? o esto hará que este código sea una pesadilla desordenada y pisada.

Gracias.

+1

tu título dice winform pero mencionas page_load. ¿Esto es winforms o webforms? –

+1

azúcar! lo siento. Form_load – RedPanda

+0

No se utilizan suficientes expresiones alternativas de consternación. : P – Russell

Respuesta

2

El tamaño del código no es una métrica que debe usar para determinar si se debe trabajar en un subproceso diferente. La peor duración de ejecución del caso es.

En primer lugar, no hay muchos diseños de UI en los que desencadenar mucho trabajo en Form_Load sea realmente deseable. Si es posible, generalmente:

  • Inicie ese trabajo antes de abrir el formulario directamente en respuesta a una acción del usuario.
  • Mueva todo el trabajo a segundo plano y actualice de forma asincrónica (¿enlazar?) Los resultados al formulario.
  • Retrasa el trabajo hasta que el usuario realice específicamente alguna acción que lo requiera.

Sus usuarios querrán/esperan que sus formularios sean extremadamente rápidos y receptivos, independientemente de la cantidad de trabajo que se realice. Ejecutar operaciones potencialmente de larga duración durante Form_Load siempre resultará en una mala experiencia del usuario.

BackgroundWorker es solo un mecanismo para realizar el trabajo de forma asincrónica, hay muchos otros. Debe elegir el que sea más apropiado para cada situación.

+0

Este fue el problema que tuvimos. Algunas llamadas de código web_service en Form_load pero el servicio web es una demora en algún momento, la UI deja de responder y el cliente piensa que está rota. El software anterior estaba en powerbuilder y se convirtió en C#, convirtiendo cada función en web_service. Están esperando más rápido que el software anterior, pero estamos sacando el doble de datos que antes: '(. Agradecemos su respuesta. – RedPanda

1

BackgroundWorker se usa normalmente para hacer que la interfaz de usuario de Winforms sea más receptiva. Puede usarlo para el procesamiento en segundo plano en una aplicación web, pero yo no; Uso un ThreadPool en un servicio de Windows.

1

Es bueno pegar código potentailly de larga duración en un trabajador de segundo plano para que su aplicación siga siendo receptiva, pero no hay necesidad de poner todo como trabajador de segundo plano.

Si su código llama a un servicio web (o cualquier tipo de sistema externo que pueda agotar el tiempo de espera), o hace algo que tarde más de unos segundos, sería un buen candidato para ponerlo en segundo plano Trabajador, sin embargo, si algo toma constantemente menos de un segundo o menos para ejecutarlo, probablemente no me molestaría.

+0

Tiene problemas para llegar a un acuerdo. El tiempo que ** típicamente ** tarda no es importante aquí. Lo importante es cuánto tiempo ** podría ** tomar (el peor caso). – hemp

1

A Trabajador de fondo tardará más tiempo en crear y destruir el hilo para el trabajador de segundo plano. Si se trata de un pequeño fragmento de código (en lo que respecta al procesamiento), puede ser más rápido utilizar el hilo de interfaz de usuario principal.

Si la clave es el mantenimiento, tal vez la solución sea utilizar trabajadores en segundo plano para el procesamiento. Un tipo de marco personalizado que aborde automáticamente los detalles puede hacer que el código sea aún más fácil de mantener.

Depende de varios factores:

  • El número de grandes trozos pequeños/de código - esto afectará el número de subprocesos que se ejecutan al mismo tiempo.
  • La importancia de la capacidad de respuesta y el rendimiento para la aplicación
  • La importancia de la capacidad de mantenimiento/escalabilidad para la aplicación.
0

Parece que, de su referencia a "Page_Load", está implementando esto en un formulario web ASP.NET. Si ese es el caso y está intentando invocar un servicio web de forma asincrónica, entonces debe usar las funciones de invocación Inicio y Fin del servicio. Esto funciona especialmente bien si necesita llamar a múltiples servicios web al mismo tiempo en lugar de llamarlos uno a la vez.

¡Disfrútalo!

+0

El OP aclaró esto en el comentario. Ajustaré la pregunta para corregir el error. – Russell

1

Si es una buena idea o no, depende mucho de las características específicas de su problema. ¿Tiene que extraer todos los datos en una sola llamada o puede hacerlo en partes independientes?

Si se trata de una llamada de servicio web de larga ejecución, entonces ponerlo en un hilo no hará nada por usted. Su mejor caso sería varios trozos independientes de larga duración que tardan aproximadamente la misma cantidad de tiempo en regresar.

Además, en formularios web (ya que mencionas Page_Load) IIRC estarás compartiendo el grupo de subprocesos con asp.net, y puede hacer que su aplicación sea menos receptiva en general en algún umbral de solicitudes/usuarios simultáneos.

1

Personalmente, no pondría código en un hilo de trabajo a menos que el código comprendiera un proceso específico que estaba interfiriendo con la capacidad de respuesta de la UI. No hay ninguna razón por la que pueda pensar poner todo en un hilo de trabajo. En general, solo tiene problemas de respuesta cuando está esperando un recurso externo, como un servicio web (a menos que esté calculando números primos en Form_Load :-).

Si no ha explorado las llamadas al servicio web asíncronas, le recomiendo echar un vistazo. Las llamadas asíncronas manejarán su subproceso por usted, siempre es algo bueno.

+0

Gracias. Voy a servicio web asincrónico "Hello World". : P – RedPanda

Cuestiones relacionadas