Jak zaimplementować plik async.Delete/Create/Move?

Question

Ponieważ muszę wykonać wiele operacji we/wy plików w mojej aplikacji, Postanowiłem zaimplementować je asynchronicznie. Patrząc na MSDN, nie ma asynchronicznych odpowiedników dla File.Create, File.Delete i File.Move. Jak dowiedziałem się, powodem jest nieistnienie asynchronicznego realizacji Win32 dla pliku usuwać, tworzyć lub przenieść, więc skończyło się następujące rozwiązanie:

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); }); 
} 

Uwzględniając Paradigma "Don’t use Task.Run in Libraries", zastanawiam się, czy istnieje lepsza implementacja czy powinienem zrezygnować z kodu synchronicznego?

Wielkie dzięki z góry!

Edits:

---

• Poprawiono kod na podstawie Peter Duniho zalecenia
• dodał link do oryginalnego blogu dostarczonych przez Sriram Sakthivel

Answer 1

Jeśli musisz to zrobić, Napisałbym takie metody (uwaga: chętnie się zgadzam, że to właśnie Stephens Cleary i Toub namawiają nas, abyśmy tego nie robili):

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); }); 
} 

Spowoduje to wyczyszczenie kodu i wyeliminowanie nadmiernego kontekstu/przełączania wątków.

W kontekście programu opartego na GUI, wydaje się, że dobrze jest używać takich wrapperów. Myślę, że dopóki nie stworzysz zupełnie nowej biblioteki z synchronicznymi i asynchronicznymi interfejsami API równolegle, jak to opisano w artykułach, o których mowa, nie jest to straszne.

Jednak dla mnie, większym problemem jest to, że żadna z tych operacji nie potrwa wystarczająco długo, aby uzasadnić ich asynchroniczne w pierwszej kolejności. To znaczy. Zwykle powodem, dla którego uruchamiasz różne rzeczy w wątku UI, jest fakt, że twój wątek interfejsu użytkownika nie może czekać na zakończenie operacji. Ale tutaj, dla każdej z tych operacji, akt wysyłania operacji do puli wątków, a następnie przechwytywanie z kontynuacją po jej zakończeniu, może dodać do twojego programu tyle samo wydajności, co sama operacja.

To jest dla , że zalecam, aby w ogóle nie przeszkadzał z asynchroniczną wersją metod. Wystarczy bezpośrednio wywołać metody Create(), Delete() i Move() z interfejsu użytkownika.

(Uwaga: jeden wyjątek od powyższego jest, jeśli do czynienia z udziału sieciowego lub różnych objętościach, gdzie Move() obejmuje faktycznie kopiowania danych więc nawet tam, to wielka ogromna „to zależy” Podobnie, podczas Delete() i Create().. Zwykle byłaby szybka nawet w sieci, mogliby zająć trochę czasu, jeśli operacja rzeczywiście zakończy się niepowodzeniem.Możesz rzeczywiście mieć dobry przypadek użycia do uruchamiania operacji asynchronicznie tam.