È utile per ThreadPool.QueueUserWorkItem?

Question

È utile per ThreadPool.QueueUserWorkItem?

#1 da (4 voti)

0

Ho un'applicazione che, tra le altre cose, importa i documenti, quindi invia le e-mail alle parti necessarie per informarli che un documento è stato importato.

Risulta che determinare chi inviare per email, quindi eseguire l'invio via email, è ciò che richiede più tempo. Stavo pensando di fare qualcosa del genere:

var document = ImportDocument();
ThreadPool.QueueUserWorkItem(s => SendEmail(document.Id));
return document;

... simile a DelayedJob in Rails, se questo aiuta. Ha senso in questo contesto? Cosa faresti?

c# multithreading

posta Matt Grande 26.06.2012 - 16:18

fonte

1 risposta

Leggi altre domande sui tag c# multithreading

Programmazione per cornici digitali 2D Image Creator per un videogioco

score 4 · Answer 1

Sì, sembra un approccio abbastanza ragionevole.

Ad un livello più ampio, questo è legato alla gestione del lavoro.
Hai un'attività principale (importa il documento) e alcune attività secondarie correlate attivate dall'attività principale (notifica e-mail, archiviazione, ecc.).

In genere, le attività secondarie devono essere asincrone rispetto all'attività principale, in quanto non influiscono in realtà sulla dichiarazione di completamento dell'attività principale. IMO, se fa influenzano l'attività principale dichiarata completa, allora faranno parte dell'attività principale, non di un'attività secondaria.

Potresti anche avere un oggetto dedicato che gestisce le notifiche email. Avrebbe una coda (o equivalente) per ricevere la notifica del documento importato e si avvierebbe all'avvio di un evento di notifica. Se ti ritroverai con una notifica in uscita, considera questo approccio. Eviterà il rallentamento della rotazione (e del basso) di tutti questi thread e eviterà di sovraccaricare il sistema con attività di tipo asincrone secondario.