2009-07-07 9 views
5

Come molti di voi sanno, lo spazio dei nomi System.IO è progettato in modo abissale. Vorrei una libreria gratuita che avvolga perfettamente la funzionalità IO del file (leggi: non richiede il passaggio di stringhe dappertutto). Ricordo di aver letto qualche tempo fa che c'è una piccola manciata di queste librerie già scritte (e l'autore era sorpreso che non ce ne fossero altre). Penso che sia stato uno dei ragazzi su devlicious o codebetter o Los Techies a fare uno di questi.Una buona libreria IO di file TDD-Friendly .NET

Qualcuno sa di cosa sto parlando o un altro buon wrapper IO File?

Edit: Suppongo che dovrei specificare che io Test Driven Development e le mie preoccupazioni sono in gran parte (ma non del tutto) intorno facilità il test di System.IO.

+0

Sarei interessato a sentire la tua giustificazione affermando che lo spazio dei nomi System.IO è "abysmally designed". Personalmente ho trovato che sia molto ben progettato, come la maggior parte dei BCL. – Noldorin

+2

È solo un mucchio di metodi su classi statiche - quasi OO-y. È quasi impossibile e alle unit test class che eseguono l'elaborazione dei file senza scrivere wrapper per la loro funzionalità. A malapena un'interfaccia nel sito. –

+0

FileInfo non è una classe statica. –

risposta

3

Cosa c'è di sbagliato in System.IO.FileInfo?


Ero curioso, quindi ho iniziato a creare un set di wrapper usando ReSharper. Mi ci sono voluti 16 minuti, e non l'ho ancora testato, e non so se soddisfi le tue esigenze. Eppure, ho pensato di delineare il processo che ho usato:

  1. Creare un nuovo progetto di libreria di classi
  2. Fai Class1 pubblica e rinominarlo in essere FileSystemInfoWrapper
  3. dargli un campo _fsi privata di tipo FileSystemInfo (risolvere la classe per ottenere il namespace importati)
  4. clic sul campo e scegliere di inizializzare nel costruttore
  5. fare nuovamente clic sul campo e utilizzare ReSharper -> Codice -> Genera (Alt + Ins); Scegli Genera membri delegati; Fai clic su "Pubblica" per ottenere tutti i membri pubblici
  6. Stesse per FileInfo, ma anche derivare da FileSystemInfoWrapper e revoca i membri duplicati (ReSharper avrebbe potuto fare meglio qui)
  7. Lo stesso vale per DirectoryInfo, ma anche derivare da FileSystemInfoWrapper e risolvere i duplicati
  8. Per ciascuno dei wrapper, fare clic sulla classe quindi utilizzare ReSharper-> Refactor-> Estrai interfaccia
  9. Hanno IFileInfoWrapper e IDirectoryInfoWrapper derivano dalla IFileSystemInfoWrapper, e rimuovere i duplicati.

Il risultato sono interfacce che includono i metodi e le proprietà delle classi corrispondenti e le classi concrete che delegano alle classi originali e implementano le interfacce. Dovresti quindi essere in grado di creare le tue classi di simulazione e modificare il codice per utilizzare le interfacce invece di utilizzare direttamente le classi concrete System.IO.

+0

Supponiamo di avere una classe che fa qualcosa per tutti i file in una directory. Come posso testarlo? Posso passare un oggetto DirectoryInfo ma come faccio a prenderlo in giro? Come posso eliminare l'elenco di oggetti FileInfo che fornirà? Come farò in modo che il test non interagisca effettivamente con il file system? –

+1

Assolutamente, posso ovviamente creare i miei wrapper, ma so che le persone hanno già fatto quel lavoro, ottimizzato, trovato i bug, ecc. Questa era la mia domanda. –

+0

@George: il codice fa qualcosa nella directory o in tutti i file? In tal caso, non avrebbe più senso da una prospettiva di scalabilità e riusabilità passare in una matrice di FileInfo o di stringhe piuttosto che in una particolare directory? –

2

Sono curioso di cosa sia così abissale riguardo al design dello spazio dei nomi System.IO. Certo, scegliere una particolare interfaccia o classe può essere in qualche modo un esercizio arbitrario, ma non ho familiarità con il problema di dover passare le stringhe dappertutto.

Forse potresti dare qualche informazione in più sul tuo particolare problema?


EDIT

È sembrano indicare che si desidera le classi che si basano sullo System.IO spazio dei nomi che vi permetterà di testare senza scrivere sul file system. Non vedo come si possa testare adeguatamente una funzione che scrive sul file system senza, beh, scrivendo sul file system. Se si desidera testare la logica da una prospettiva di scrittura, quindi consentire alle funzioni di prendere System.IO.Stream o System.IO.TextWriter, a seconda di quale sia più appropriato. Ciò ti consentirà di testare i vari componenti del tuo codice senza necessariamente avere alcun impatto esterno; basta passare un System.IO.MemoryStream anziché uno System.IO.FileStream. Ovviamente non ti imbatterai in problemi come l'esaurimento dello spazio, l'accesso negato, ecc., Ma non potrai mai incontrare quegli errori senza eseguire live dal file system. Ecco perché è possibile esporre le funzioni esterne che richiedono System.IO.FileInfo o un percorso di stringa (o un array/IEnumerable<> di entrambi, qualunque sia il necessario) in grado di fornire un altro livello di test in tempo reale.

Lo spazio dei nomi System.IO è piuttosto ben popolato e non ho mai utilizzato un approccio particolarmente non OO.

+0

Mi piace fare TDD. Il che significa che ho bisogno di qualcosa di più delle classi e dei metodi statici. Ma per quanto riguarda il passare le stringhe, considera Directory.GetFiles() che prende una directory come stringa e restituisce i file come una stringa di array. Per ulteriori informazioni, rispondi a John –

+0

Allora perché non DirectoryInfo e FileInfo?Questi sono entrambi i tipi che portano un paradigma OO alla gestione dei file. Ad un certo punto dovrai trattare con le stringhe quando parli di percorsi. Non vedo davvero alcun vantaggio per la libreria NDepends a cui ti sei collegato. Mi sto perdendo quello che stai cercando? –

3

Penso che stiate cercando this question e this blog post. Ho solo avvolto System.IO.File e System.IO.Directory. No FileInfo o altre cose.

+0

Grazie, mauricio. Questo non è esattamente quello che stavo cercando (voglio dire, non è l'articolo esatto), ma potrei finire per usarlo piuttosto che cercare di scavare attraverso codebetter per trovare quello che era. –

2

Ok, sono andato a scavare. This è l'articolo a cui mi riferivo.

E this è l'API (generato dal progetto NDepend

0

C'è una serie piuttosto completa di adattatori forniti in http://systemwrapper.codeplex.com. Troverete praticamente tutti System.IO è avvolto, insieme a un bel po 'altra Spazi dei nomi di sistema (il wrapping della classe DateTime è sempre una buona mossa se stai lavorando con calcoli time-sensitive)

Problemi correlati