2010-05-27 7 views
5

Ciò che intendo con questa domanda è, quando è necessario memorizzare o passare un URL in giro, usare una stringa è probabilmente una cattiva pratica, e un approccio migliore sarebbe utilizzare un tipo di URI. Tuttavia è così facile rendere le cose complesse più complesse e gonfie.Esiste un tipo più corretto per passare il percorso del file e il nome del file a un metodo

Quindi, se sto andando a scrivere su un file su disco, devo passargli una stringa, come il nome del file e il percorso del file, o c'è un tipo migliore che sarà più adatto al requisito?

Questo codice sembra essere goffo e soggetto a errori? Avrei anche bisogno di fare un bel po 'di controllo se si tratta di un nome di file valido, se la stringa contiene dati e la lista continua.

private void SaveFile (string fileNameAndPath) {// La roba normale per salvare il file }

risposta

5

Una stringa va bene per il nome file. Il .Net Framework usa stringhe per nomi di file, che sembra soddisfacente.

Per convalidare il nome del file, è possibile provare a utilizzare un'espressione regolare o cercare caratteri non validi contro System.IO.Path.GetInvalidFileNameChars. Tuttavia, è probabilmente più semplice gestire i casi eccezionali di nomi di file non validi gestendo l'eccezione che si verificherà quando proverai a creare il file, oltre a farlo comunque ....

+0

Hmm Sto cercando di evitare che altre persone che usano il mio codice non commettano errori, le espressioni regolari non aumenterebbero il rischio che il mio codice fallisse? –

+0

Penso che tu abbia un punto. Il mio approccio personale qui non sarebbe quello di convalidare il nome del file nel tuo metodo, ma quelle erano le due idee di convalida che mi venivano in mente. L'utente del tuo metodo dovrebbe, probabilmente, assicurarsi di passare un nome file valido al tuo metodo, o aspettare che venga sollevata un'eccezione. – philhobgen

4

Sfortunato come è, stringa è il modo idiomatico di fare questo in .NET - se guarda cose come i costruttori FileStream ecc., usano le stringhe.

È possibile considerare l'utilizzo di FileInfo (o DirectoryInfo) ma sarebbe un po 'insolito.

+0

Quella è la cosa, sarà necessario utilizzare 2 oggetti solo per la posizione e il nome del file. Tuttavia, la sicurezza che ti darebbe non merita il sovraccarico in memoria? Mi rendo conto che le stringhe sono la norma, ma è corretto? –

+0

@Rihan: Dipende - a quale sicurezza stai pensando, esattamente? Non sono sicuro che 'FileInfo' abbia molta convalida. Ti suggerisco di pensare a quali errori vuoi evitare e vedere se FileInfo ti aiuta o no. –

1

È possibile utilizzare FileInfo (da System.IO) per passarlo, ma le stringhe sono più o meno standard quando si fa riferimento ai file.

È sempre possibile utilizzare Path.GetFileName ({yourstring}) per ottenere il nome file dal percorso.

0

La stringa va bene, ma tu dovrebbe fare un po 'di sforzo per assicurare che il file venga salvato nella directory che ci si aspetta.

0

Se si sta lavorando con un percorso file, una stringa è normale.

Se si sta lavorando con un URL si potrebbe considerare l'utilizzo della classe System.Uri ad es.

Uri myUri = new Uri(myUrl, UriKind.Absolute); 

Questo vi permetterà di lavorare con le proprietà come uri.Host, uri.Absolute percorso ecc vi darà anche un array di stringhe (segmenti) per le sottocartelle separate nella url.

MSDN informazioni qui: System.Uri

+0

Beh, questo è esattamente il motivo per cui ho fatto questa domanda. Ho lavorato con URL come stringhe a causa del codice legacy e quindi ho avuto la possibilità di implementare alcune nuove funzionalità e modificato una sezione del codice, per non utilizzare le stringhe, ma piuttosto un Uri. E rende il codice molto più leggibile e robusto. Sono solo sorpreso che gestirà ancora una posizione su un file su disco come una stringa. Immagino che sia proprio così com'è adesso. –

+1

I nomi di file come stringhe sono la norma. Non dimenticare che puoi usare System.IO.Path per manipolare in modo più sicuro quelle stringhe, ad es. Path.Combine(), Path.GetFileName() e Path.GetFullPath() ... –