これは面白いアイデアですが、このデザインには私を悩ませる何かがあります。設計ですでにこれに対処している場合は、ご容赦ください。しかし、あなたのデザインが の単純なラッパーFileStream
である場合、微妙ではありますが重大な問題があると思います。
ストリームが閉じているときにファイルを削除する場合、ファイル内のデータを実際に使用する唯一の方法FileAccess
は、 ReadWrite
. 正しい?つまり、次のようなコードでファイルを使用します。
using (TempFileStream t as new TempFileStream())
{
WriteDataToTempFile(t);
t.Seek(0, SeekOrigin.Begin);
ReadDataFromTempFile(t);
}
私が見る問題はReadDataFromTempFile
、ファイルが読み取り/書き込みアクセスではなく、読み取りアクセスで開かれることを期待していることです。そして、これは、見つけるのが非常に難しいと思われるいくつかのバグへの扉を開きます. 次のようなコードを検討してください。
using (TempFileStream t as new TempFileStream())
{
MyClass o = new MyClass(o);
o.TempStream = t;
o.ProduceOutput();
t.Seek(0, SeekOrigin.Begin);
o.ProcessOutput();
}
...これと比較すると:
MyClass o = new MyClass();
string n = Path.GetTempFileName();
using (FileStream s = new FileStream(n, FileMode.Create, FileAccess.Write))
{
o.TempStream = t;
o.ProduceOutput();
}
using (FileStream s = new FileStream(n, FileMode.Open, FileAccess.Read))
{
o.TempStream = t;
o.ProcessOutput();
}
File.Delete(n);
確かに、最初の方法は 2 番目の方法よりも短いです。ただし、2 番目ProcessOutput
のメソッドは、に書き込むメソッドを呼び出すと例外をスローしTempStream
ます。(または、 set アクセサーが に書き込むメソッドへの呼び出しをディスパッチするイベント ハンドラーのイベントを発生させる set アクセサーを持つプロパティを設定しますTempStream
。これにより、この問題が発生する可能性があります。) 最初のものは、明らかな理由もなく予期しない結果を生成します。
これを回避するには、クラスで基になるものを usingTempFileStream
で開く必要があると思います。次に、これを閉じて を使用する新しいメソッドを作成するメソッドを実装します。これを行うと、ファイルが読み取りアクセス用に開かれている間にファイルに書き込もうとするメソッド (またはその逆) は、少なくとも例外をスローします。FileStream
FileAccess.Write
Rewind
FileStream
FileAccess.Read