E '"sbagliato" / design sbagliato mettere un thread / background worker in una classe?

Should I create my class without it and use a background worker to operate on that class?

Sì, dovresti. E ti dirò perché - stai violando il principio di singola responsabilità . Accoppiando strettamente la classe che accede al documento excel con come accede al documento excel, si elimina la possibilità per il codice "controller" (qualsiasi codice che lo utilizza) di farlo in un modo diverso. Quanto diverso, puoi chiedere? Cosa succede se il codice del controller ha due operazioni che impiegano molto tempo ma vogliono che siano sequenziali? Se si consente al controller di gestire il threading, è possibile eseguire insieme attività a esecuzione prolungata in un thread. Cosa succede se si desidera accedere al documento excel da un contesto non-UI e non è necessario che venga eseguito il thread?

Spostando la responsabilità di eseguire il threading verso il chiamante, si consente una maggiore flessibilità del codice, rendendolo più riutilizzabile.

È buona norma che le operazioni dell'interfaccia utente operino in un thread separato dalle attività in background. Altrimenti l'interfaccia utente non risponde quando l'applicazione è occupata.

Se puoi separare la parte che funziona nel thread in background nella sua classe, il codice sarà più pulito.

Vorrei separare l'interfaccia utente dall'attività in background utilizzando classi separate. Ciò incoraggia la separazione delle preoccupazioni. Il codice dell'interfaccia utente e la logica aziendale non vanno mischiati.

Da quello che ricordo su BackgroundWorkers è che forniscono un numero di metodi di convenienza come la possibilità di inviare aggiornamenti di avanzamento all'interfaccia utente. Non c'è una regola che dice che non puoi usarlo da una classe diversa però.

Inoltre, se stai eseguendo l'iterazione che non richiede l'elaborazione di elementi in un ordine specifico, considera l'utilizzo di ThreadPool invece (o se sei su .NET 4 usa Task Parallel Library ).