クラスにスレッド/バックグラウンドワーカーを配置するのは「間違った」/悪い設計ですか？
Excel（C＃および.Net 4）から読み取るクラスがあり、そのクラスには、UIの応答性を維持しながらExcelからデータをロードするバックグラウンドワーカーがあります。私の質問は次のとおりです。クラスにバックグラウンドワーカーがいるのは悪い設計ですか。それなしでクラスを作成し、バックグラウンドワーカーを使用してそのクラスを操作する必要がありますか？私はこの方法でクラスを作成することに本当に問題は見られませんが、それでも私は初心者なので、続行する前に確認することを考えました。
私のコードが機能するのでスタックオーバーフローにあるべきではないと思うので、この質問がここに関連していることを願っています。これは単なる設計上の問題です。
それなしでクラスを作成し、バックグラウンドワーカーを使用してそのクラスを操作する必要がありますか？
はい、そうすべきです。そして、その理由をお話しします-あなたは 単一の責任の原則 に違反しています。 ExcelドキュメントにアクセスするクラスとExcelドキュメントにアクセスするhowを密結合することで、「コントローラー」コード（任意のコードこれを使用して別の方法で行います。どのように違うのですか？コントローラーコードに2つの操作があり、時間がかかりますが、それらの操作を順次にしたい場合はどうなりますか？コントローラーにスレッド処理の機能を許可すると、長時間実行するタスクを両方とも1つのスレッドで実行できます。非UIコンテキストからExcelドキュメントにアクセスし、スレッド化する必要がない場合はどうなりますか？
スレッド化の責任を呼び出し元に移すことにより、コードの柔軟性を高め、再利用性を高めることができます。
UI操作をバックグラウンドタスクとは別のスレッドで動作させるのは良い設計です。そうしないと、アプリケーションがビジーのときにUIが応答しなくなります。
バックグラウンドスレッドで機能する部分を独自のクラスに分離できる場合、コードはよりクリーンになります。
個別のクラスを使用して、UIをバックグラウンドタスクから分離します。そうすることで、懸念の分離が促進されます。 UIコードとビジネスロジックを混在させないでください。
BackgroundWorkersについて私が覚えていることから、UIに進行状況の更新を送信する機能など、いくつかの便利なメソッドが提供されていることです。ただし、別のクラスからは使用できないというルールはありません。
また、アイテムを特定の順序で処理する必要がないイテレーションを行う場合は、代わりに ThreadPool を使用することを検討してください（または.NET 4を使用している場合は Task並列ライブラリ ）。