Esta es una idea interesante, pero hay algo en este diseño que me preocupa. Perdóname si ya has abordado esto en tu diseño. Pero si su diseño es simplemente una envoltura simple alrededor de FileStream
, hay un problema sutil, pero creo que significativo.
Si va a eliminar el archivo cuando se cierra el flujo, lo que significa que la única manera de realmente uso de los datos en el archivo es si el FileAccess
es ReadWrite
. ¿Correcto? En otras palabras, usted va a utilizar el archivo con el código que se parece a esto:
using (TempFileStream t as new TempFileStream())
{
WriteDataToTempFile(t);
t.Seek(0, SeekOrigin.Begin);
ReadDataFromTempFile(t);
}
El problema que veo es que ReadDataFromTempFile
espera que el archivo que se abrirá para acceso de lectura, no acceso de lectura/escritura. Y esto abre la puerta a algunos errores que creo que serán muy difíciles de encontrar. Considere código como este:
using (TempFileStream t as new TempFileStream())
{
MyClass o = new MyClass(o);
o.TempStream = t;
o.ProduceOutput();
t.Seek(0, SeekOrigin.Begin);
o.ProcessOutput();
}
... si se compara con esto:
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);
Claro, el primer método es más corta que la segunda. Pero el segundo método lanzará una excepción si ProcessOutput
llama a un método que escribe en TempStream
. (O establece una propiedad cuyo acceso de conjunto provoca un evento cuyo controlador de eventos distribuye una llamada a un método que escribe en TempStream
, que indica cómo este problema probablemente terminará sucediendo). El primero solo producirá resultados inesperados sin motivo aparente.
Puede evitar esto, creo, teniendo su clase TempFileStream
abra el FileStream
subyacente usando FileAccess.Write
. A continuación, implemente un método Rewind
que cierra este FileStream
y crea uno nuevo que usa FileAccess.Read
. Si lo hace, cualquier método que intente escribir en el archivo mientras está abierto para acceso de lectura (o viceversa) arrojará al menos una excepción.
¿Tiene que usar FileStream para esto, no puede usted utilizar MemoryStream? De esta forma, no tiene que manejar todos los posibles problemas relacionados con la eliminación del archivo. – armannvg
@armannvg, ¿de qué problemas estás hablando? Es un almacenamiento temporal para el archivo muy grande antes de que se grabe en la base de datos. – sh0gged
Solo los problemas habituales de eliminación de archivos -> IOException, UnauthorizedAccessException etc. Pero si está trabajando con un archivo muy grande, entonces MemoryStream no es una opción – armannvg