.net - getfilename - string[] files directory getfiles

Buenas razones para pasar rutas como cadenas en lugar de usar DirectoryInfo/FileInfo

Question

En mi nuevo código no estoy usando cadenas para pasar rutas de directorio o nombres de archivos. En cambio, estoy usando DirectoryInfo y FileInfo, ya que parecen encapsular mucha información.

He visto muchos códigos que usan cadenas para pasar información del directorio, luego se "dividen" y "mid" y "instr" en declaraciones largas e incomprensibles hasta que obtienen la parte del directorio que están buscando.

¿Hay alguna buena razón para pasar caminos como cadenas?

Answer 1

Creo que necesitas una clase para encapsular una ruta de archivo o directorio, en lugar de usar cadenas en bruto y manipularlas usando la clase estática System.IO.Path. Sin embargo, no encuentro que DirectoryInfo y FileInfo sean adecuados , ya que parecen estar destinados más para realizar manipulaciones de archivos / directorios en lugar de operaciones de ruta. Si crea una clase personalizada para la manipulación de rutas, puede proporcionar una funcionalidad de manipulación de rutas más fácil de usar .

Answer 2

DirectoryInfo y FileInfo son tremendamente pesados ​​para pasar si todo lo que necesita es una ruta. Estaría más preocupado por la basura "split and mid and instr". Aprende las formas de:

Path.GetFileName
Path.GetDirectoryName
Path.Combine
etc ...

Esos son de la clase System.IO.Path, por cierto.

Answer 3

En general, creo que es mejor mantener la información en FileInfo / DirectoryInfo. Hay una gran cantidad de funciones útiles en estas clases, así como una gran cantidad de seguridad, ya que es mucho más fácil verificar la existencia de un archivo, ver el archivo especificado originalmente, etc.

El único lugar donde (potencialmente) pasaría una ruta como una cadena en lugar de usar FileInfo y DirectoryInfo si la ruta se pasara a través de los Dominios de Aplicación o entre procesos, etc.

FileInfo y DirectoryInfo funcionan bien a través de los límites de AppDomain (ya que son serializables), pero tienen una gran cantidad de gastos generales en esta situación. Si las cosas van y vienen mucho, podría tener un impacto.

Sin embargo, me quedaría con FileInfo y DirectoryInfo en este caso, a menos que descubriera que había un problema notable durante mi creación de perfiles y estaba tratando de reducir la cantidad de datos serializados. Si no tuviera problemas de rendimiento, seguiría usando estas clases, ya que ofrecen mucha seguridad y funcionalidad.

Answer 4

He encontrado problemas al pasar FileInfo a DMZ. Por lo que puedo ver, corríjame si me equivoco, FileInfo realiza una verificación de permisos al deserializar y eso no funcionará desde DMZ y resultará en una "ruta no encontrada". Crea y pasa un objeto personalizado con los datos que en su lugar.

Answer 5

Una diferencia significativa entre la cadena de ruta y FileInfo a tener en cuenta, que se puede resumir en las siguientes pruebas:

Un FileInfo refleja la información sobre el archivo desde el momento en que se creó la instancia : se puede eliminar / modificar y FileInfo no reflejará eso.

[TestMethod]
        public void TestFileInfo()
        {
            var path = @"C:/Users/bjarmuz/Desktop/aybabtu.txt";
            File.WriteAllText(path, "All your base are belong to us!");
            var file = new FileInfo(path);

            Assert.IsTrue(file.Exists);
            File.Delete(file.FullName);
            Assert.IsTrue(file.Exists);
            Assert.IsFalse(File.Exists(file.FullName));
        }

  [TestMethod]
        public void TestFileInfo()
        {
            var path = @"C:/Users/bjarmuz/Desktop/aybabtu.txt";
            File.WriteAllText(path, "All your base are belong to us!");
            Thread.Sleep(1000);

            var file = new FileInfo(path);
            var date = DateTime.UtcNow;

            Assert.IsTrue(file.LastWriteTimeUtc< date);

            File.WriteAllText(path, "No!");
            Assert.IsTrue(File.GetLastWriteTimeUtc(file.FullName)> date);

            Assert.IsFalse(file.LastWriteTimeUtc > date);
        }

Esto puede ser un tanto engañoso, y si su código pasa por FileInfos en lugar de cadenas, es posible que vea resultados incorrectos para las propiedades como Exists o Last[..]Time , lo cual no ocurriría si usara File.Get[...]() métodos.

Sin embargo, por otro lado, tampoco debe confiar en el método File.Exists (), ya que el archivo se puede crear / eliminar justo después de ejecutar las pruebas. La forma correcta de hacerlo es NO realizar esta comprobación y, más bien, aceptar que puede lanzar la excepción IO (y estar preparado para manejarlo correctamente). Más información en este gran artículo https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/

Además, una "ventaja" significativa de FileInfo / DirectoryInfo es que protege su método (y los consumidores del método) de esto:

void SaveEntity(Entity theThing, string path)
{
    //now, based on the signature, you don''t know whether you need file path or directory path

}

//void SaveEntity(Entity theThing, DirectoryInfo path) {}
//void SaveEntity(Entity theThing, FileInfo path) {}

Answer 6

Una vez que la ruta está en una aplicación (es decir, no en un archivo de configuración de texto plano), no, no hay una buena razón.

El único momento en el que puedo pensar que podría ser útil es cuando se interopera con un código que solo acepta rutas como cadenas.