.net - make - ¿Con qué frecuencia utiliza System.Component.BackgroundWorker en sus UI?(si alguna vez)
thread c# windows form (6)
@Gulzar Gracias por este dato: debe crearse y ejecutarse desde el hilo de UI para que el cambio de hilo ocurra correctamente.
Una cosa a tener en cuenta cuando uso un trabajador de segundo plano que he encontrado es la manipulación de excepciones.
Si se lanza una excepción en el proceso asincrónico, no arrojará una excepción al hilo principal, el proceso finalizará y el evento BackgroundWorker RunWorkerCompleted se activará con el error oculto en RunWorkerCompletedEventArgs.Error.
Me gusta el hecho de que BackgroundWorker tiene una funcionalidad que es fácil de implementar pero aún más fácil de implementar incorrectamente de una manera sutil, como la cancelación.
Estoy seguro de que una interfaz de usuario receptiva es algo que todos buscan y la forma recomendada de hacer las cosas es utilizar BackgroundWorker para esto.
¿Le resulta fácil trabajar con él? ¿Lo usas a menudo? ¿O tienes tus propios marcos para tareas largas y procesos de informes?
Descubrí que lo estoy usando bastante y que incluso uso sus delegados allí donde necesito algún tipo de informe de progreso.
BackgroundWorker hace las cosas mucho más fáciles. Una cosa que encontré por las malas es que Backgroundworker sí mismo tiene afinidad de hilos a pesar de que se supone que oculta el problema de cambio de hilos. No cambia automáticamente al hilo de UI en todos los casos. Debe crearse y ejecutarse desde la secuencia de la interfaz de usuario para que la conmutación de hilos ocurra correctamente.
La programación multiproceso es difícil de entender al principio (y los veteranos aún fallan a veces) y BackgroundWorker lo hace un poco más fácil de usar. Me gusta el hecho de que BackgroundWorker tiene una funcionalidad que es fácil de implementar pero aún más fácil de implementar incorrectamente de una manera sutil, como la cancelación. Lo uso si tengo y necesito una actualización de progreso, para poder mostrar una barra de progreso significativa.
Si no, utilizo un subproceso (o tomo prestado de ThreadPool), porque no necesito toda la funcionalidad de BackgroundWorker y soy lo suficientemente competente con los subprocesos para iniciar un subproceso y esperar a que se detenga.
En cuanto a los delegados para tareas no relacionadas, utilizo las de las clases Thread, como plain void ThreadStart() , o creo el mío propio.
Lo he usado una vez y estaba bastante contento con eso. A menudo, no hay necesidad de multihilo "grande", pero solo para 2 subprocesos (UI y Worker), y funciona realmente bien sin tener que preocuparse demasiado por la lógica de subprocesamiento subyacente.
Lo uso con bastante frecuencia para tareas como indicación de progreso y carga y procesamiento de datos de fondo.
Recientemente encontré el caso de uso que no se admite fuera de la caja. Es una "Tarea sobresatible". Sin embargo, Patric Smacchia tiene una buena solución .
Mi mayor problema con la clase de trabajadores de segundo plano es que realmente no hay forma de saber cuándo el trabajador ha terminado debido a la cancelación. El BackgroundWorker no expone el hilo que utiliza, por lo que no puede usar las técnicas estándar para sincronizar la terminación del hilo (join, etc.). Tampoco puedes esperar en un ciclo en el hilo de UI para que finalice porque el evento RunWorkerCompleted nunca terminará disparando. El truco que siempre he tenido que usar es simplemente establecer un indicador y luego iniciar un temporizador que continuará verificando que el trabajador de fondo termine. Pero es muy complicado y complica la lógica comercial.
Por lo tanto, es excelente siempre y cuando no necesite apoyar la cancelación determinista.