2012-03-20 16 views
6

Mamy klasę rejestrowania napisaną w języku C# przy użyciu .NET 4. Chcę dodać argument konstruktora, który opcjonalnie ustawi flagę FileOptions.WriteThrough podczas konstruowania FileStream. Ponieważ jest to powszechnie używany kod biblioteki, chcę go zmienić w jak najmniejszym stopniu.Konstruktor FileStream i domyślny rozmiar buforu

Istniejące FileStream konstruktor wezwanie:

_stream = new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read); 

Problem:

Do naszego konstruktora Dodałem opcjonalny argument bool nazwie writeDirectToDisk. Pomyślałem, że będę mógł zrobić coś takiego:

var fileOptions = writeDirectToDisk ? FileOptions.WriteThrough : FileOptions.None; 
_stream = new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read, fileOptions); 

ale nie, nie ma takiego przeciążenia! Chyba że czegoś mi brakuje, jedyne przeciążenia dostępne dla konstruktora FileStream, które akceptują argument FileOptions, również wymagają argumentu wielkości bufora!

Co próbowałem:

Próbowałem Rozmiar bufora na zero nadziei, że użyłby domyślny rozmiar bufora, ale nie zgłasza wyjątek.

Szukałem i nie mogę znaleźć statycznej właściwości lub stałej w strukturze, która określa, jaki jest domyślny rozmiar bufora.

Moje pytanie:

nie jestem na tym etapie szczególnie przeszkadzało o ile bajtów domyślny rozmiar bufora. Po prostu chcę wiedzieć, w jaki sposób mogę dodać argument FileOptions do konstruktora przy jak najmniejszym wpływie kodu?

Zastanawiam się, czy istnieje jakiś ciągły lub statyczny var, który przeoczyłem, który mógłbym użyć jako argument rozmiaru bufora lub jeśli jest przeciążenie, które przeoczyłem lub w rzeczywistości, jeśli jest jakiś mądrzejszy sposób, aby to zrobić. Ja również zastanawiam się, czy rozmiar bufora nie ma znaczenia kiedy FileOptions.WriteThrough określona jest w takim przypadku mogę to zrobić:

  if (writeDirectToDisk) 
      { 
       _stream = new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read, 1, FileOptions.WriteThrough); // 1 is the smallest value allowed, it will actually be 8 bytes 
      } 
      else 
      { 
       _stream = new FileStream(_filePath, FileMode.Append, FileAccess.Write, FileShare.Read); 
      } 

ale raczej nie, chyba że naprawdę nie ma bardziej elegancki sposób.

Odpowiedz

3

Możesz użyć własnej metody fabrycznej do zbudowania FileStream.

Poza tym, możesz odfiltrować rozmiar bufora odkrytego za pomocą reflektora (0x1000).

+0

Nie chcę wykonywać żadnego twardego okablowania, dlatego nie obchodzi mnie, jaki jest rzeczywisty domyślny rozmiar bufora. Jak skonstruować FileStream przy użyciu metody fabrycznej? Nadal utknąłem bez koniecznego przeciążenia konstruktora, prawda? –

+0

Nadal można użyć kodu "if (writeDirectToDisk) ...", aby wywołać odpowiedni konstruktor w fabryce. Tak więc test byłby tylko w jednym miejscu. A wpływ kodu będzie ograniczony do zastąpienia "nowego strumienia plików (...)" przez "MyFileStreamFactory.Create (...)" – Joe

+2

Ale nie ustawiaj rozmiaru bufora na 1 – Magnus

3

Domyślny rozmiar bufora można zobaczyć w kodzie źródłowym .Net, here.

WriteThrough nie jest obsługiwany w .Net. Możesz używać niezarządzanych wywołań Win API, jeśli naprawdę chcesz tej funkcjonalności. Spędziłem dzień na eksperymentowaniu z nim i nie ma żadnych korzyści z jego używania. Nie było to prawdą 10+ lat temu, kiedy buforowanie miało zauważalny wpływ na szybkość.

W interesie, ktoś uprzejmie napisał całą bibliotekę do wykonywania wywołań API, dostępny here.

Powiązane problemy