Come implementare un file asincrono. Elimina/Crea/Sposta?

Question

Poiché devo eseguire molte operazioni di I/O su file nella mia applicazione, , ho deciso di implementarle in modo asincrono. Guardando in MSDN, non ci sono controparti asincrone per File.Create, File.Delete e File.Move. Come ho imparato, il motivo è la non esistenza di un'implementazione asincrona Win32 per eliminazione dei file, creare o spostare, quindi ho finito con la seguente soluzione:

public static Task DeleteAsync(string path) 
{ 
    Guard.FileExists(path); 

    return Task.Run(() => File.Delete(path)); 
} 

public static Task<FileStream> CreateAsync(string path) 
{ 
    Guard.IsNotNullOrWhitespace(path); 

    return Task.Run(() => File.Create(path)); 
} 

public static Task MoveAsync(string sourceFileName, string destFileName) 
{ 
    Guard.FileExists(sourceFileName); 
    Guard.IsNotNullOrWhitespace(destFileName); 

    return Task.Run(() => { File.Move(sourceFileName, destFileName); }); 
} 

Considerando il paradigma "Don’t use Task.Run in Libraries", mi chiedo se c'è un migliore implementazione o dovrei ricorrere al codice sincrono?

Molte grazie in anticipo!

Modifiche:

---

• Migliorato il codice basato su Pietro Duniho raccomandazione
• Aggiunto il link al post originale fornito da Sriram Sakthivel

Answer 1

Se si deve fare questo, Vorrei scrivere i metodi come questo (nota: prontamente accetto che questo è esattamente ciò che Stephens Cleary e Toub ci stanno esortando a non fare):

public static Task DeleteAsync(string path) 
{ 
    Guard.FileExists(path); 

    return Task.Run(() => { File.Delete(path); }); 
} 

public static Task<FileStream> CreateAsync(string path) 
{ 
    Guard.IsNotNullOrWhitespace(path); 

    return Task.Run(() => File.Create(path)); 
} 

public static Task MoveAsync(string sourceFileName, string destFileName) 
{ 
    Guard.FileExists(sourceFileName); 
    Guard.IsNotNullOrWhitespace(destFileName); 

    return Task.Run(() => { File.Move(sourceFileName, destFileName); }); 
} 

Questo pulisce un po 'il codice ed elimina il contesto eccessivo/il cambio di thread.

Nel contesto di un programma basato su GUI, sembra opportuno utilizzare wrapper come questi. Penso che se non crei un'intera nuova libreria con le API sincrone e asincrone in parallelo, come descritto negli articoli citati, questo non è terribile.

Ma per me, il problema più grande è che nessuna di queste operazioni dovrebbe richiedere abbastanza tempo per giustificare la loro asincronia in primo luogo. Cioè la solita ragione per cui esegui le cose in un Task da un thread dell'interfaccia utente è perché il thread dell'interfaccia utente non può permettersi di aspettare mentre l'operazione viene completata. Ma qui, per ciascuna di queste operazioni, l'operazione di inviare l'operazione al pool di thread e quindi riprendere con la continuazione dopo che è stata eseguita, è probabile che aggiunga al proprio programma un carico di prestazioni pari a quello dell'operazione stessa.

E 'per che motivo che mi consiglia di non disturbare con una versione asincrona dei metodi. Basta chiamare direttamente i metodi Create(), Delete() e Move() dall'interfaccia utente.

(Nota: una sola eccezione a quanto sopra è che se si tratta di una condivisione di rete o di diversi volumi, in cui un Move() comportino dati copiando Quindi, anche lì, è un grande grande "dipende" Allo stesso modo, mentre Delete() e Create().. Normalmente sarebbe veloce anche su una rete, potrebbe richiedere un po 'se l'operazione fallirà davvero.Potresti avere un buon use case per eseguire le operazioni in modo asincrono lì).