System.Runtime.Caching.MemoryCache vs HttpRuntime.Cache - czy są jakieś różnice?

Zastanawiam się, czy są jakieś różnice między MemoryCachei HttpRuntime.Cache, który jest preferowany w projektach ASP.NET MVC?

O ile rozumiem, oba są bezpieczne dla wątków, API jest od pierwszego wejrzenia mniej więcej takie same, więc czy jest jakaś różnica, kiedy użyć którego?

HttpRuntime.Cachepobiera Cachedla bieżącej aplikacji.

MemoryCacheKlasa jest podobna do ASP.NET Cacheklasy.

MemoryCacheKlasa ma wiele właściwości i metody dostępu do pamięci podręcznej, która będzie wam znane, jeśli użyłeś ASP.NET Cacheklasę.

Główna różnica między HttpRuntime.Cachei MemoryCachepolega na tym, że ta ostatnia została zmieniona, aby umożliwić jej używanie przez aplikacje .NET Framework, które nie są aplikacjami ASP.NET.

Dodatkowe informacje:

• Blog Justina Mathew - Buforowanie w .Net 4.0
• Blog Jona Davisa - Cztery metody prostego buforowania w .NET

Aktualizacja :

Z opinii użytkowników wynika, że ​​czasami blog Jona Davisa nie działa, dlatego wrzuciłem cały artykuł jako obrazek.

Uwaga: jeśli nie jest jasne, po prostu kliknij obraz, a następnie otworzy się w przeglądarce, a następnie kliknij ponownie, aby powiększyć :)

Oto artykuł Jona Davisa. Aby zachować czytelność, wycinam przestarzałą sekcję EntLib, wprowadzenie oraz zakończenie.

Pamięć podręczna ASP.NET

ASP.NET lub zestaw System.Web.dll ma mechanizm buforowania. Nigdy nie był przeznaczony do użytku poza kontekstem sieciowym, ale może być używany poza siecią i wykonuje wszystkie powyższe zachowania związane z wygaśnięciem w pewnego rodzaju tablicy haszującej.

Po przeszukaniu Google okazuje się, że sporo osób, które dyskutowały o wbudowanej funkcji buforowania w .NET, uciekło się do korzystania z pamięci podręcznej ASP.NET w swoich projektach innych niż internetowe. Nie jest to już najbardziej dostępny i obsługiwany wbudowany system buforowania w .NET; NET 4 ma ObjectCache, do którego przejdę później. Firma Microsoft zawsze była nieugięta, że ​​pamięć podręczna ASP.NET nie jest przeznaczona do użytku poza siecią. Ale wiele osób wciąż tkwi w .NET 2.0 i .NET 3.5 i potrzebuje czegoś do pracy, a to działa dla wielu ludzi, mimo że MSDN mówi wyraźnie:

Uwaga: Klasa Cache nie jest przeznaczona do użytku poza aplikacjami ASP.NET. Został zaprojektowany i przetestowany do użytku w ASP.NET w celu zapewnienia buforowania dla aplikacji sieci Web. W innych typach aplikacji, takich jak aplikacje konsolowe lub aplikacje Windows Forms, buforowanie ASP.NET może nie działać poprawnie.

Klasa pamięci podręcznej ASP.NET to System.Web.Caching.Cache w System.Web.dll. Nie można jednak po prostu utworzyć nowego obiektu pamięci podręcznej. Musisz go pobrać z System.Web.HttpRuntime.Cache.

Cache cache = System.Web.HttpRuntime.Cache;

Praca z pamięcią podręczną ASP.NET jest udokumentowana w witrynie MSDN tutaj .

Plusy:

1. Jest wbudowany .
2. Pomimo składni .NET 1.0 jest dość prosty w użyciu.
3. Używany w kontekście sieciowym jest dobrze przetestowany . Poza kontekstami internetowymi, według wyszukiwań Google, nie jest powszechnie znane z tego, że powoduje problemy, pomimo rekomendacji firmy Microsoft, o ile używasz .NET 2.0 lub nowszego.
4. Możesz otrzymać powiadomienie za pośrednictwem pełnomocnika, gdy element zostanie usunięty, co jest konieczne, jeśli chcesz go utrzymać przy życiu i nie możesz z góry ustawić priorytetu elementu.
5. Poszczególne elementy mają elastyczność dowolnej z (a), (b) lub (c) metod wygaśnięcia i usunięcia na liście metod usuwania na początku tego artykułu. Możesz również powiązać zachowanie związane z wygasaniem z obecnością pliku fizycznego.

Cons:

1. Nie tylko jest statyczny, jest tylko jeden . Nie można utworzyć własnego typu z własną statyczną instancją pamięci podręcznej. Możesz mieć tylko jeden zasobnik dla całej aplikacji, kropka. Możesz owinąć zasobnik własnymi opakowaniami, które wykonują takie rzeczy, jak prefiksy przed wstrzyknięciem w kluczach i usuwają te prefiksy, gdy wyciągasz pary klucz / wartość z powrotem. Ale wciąż jest tylko jedno wiadro. Wszystko jest zebrane razem. Może to być naprawdę uciążliwe, jeśli na przykład masz usługę, która wymaga osobnego buforowania trzech lub czterech różnych rodzajów danych. Nie powinno to stanowić dużego problemu dla żałośnie prostych projektów. Ale jeśli projekt ma znaczny stopień złożoności ze względu na jego wymagania, pamięć podręczna ASP.NET zwykle nie wystarcza.
2. Przedmioty mogą zniknąć, chcąc nie chcąc. Wiele osób nie jest tego świadomych - nie wiedziałem, dopóki nie odświeżyłem swojej wiedzy na temat implementacji tej pamięci podręcznej. Domyślnie pamięć podręczna ASP.NET jest zaprojektowana do niszczenia elementów, gdy „wydaje się” na to ochotę. Dokładniej, zobacz (c) w mojej definicji tabeli pamięci podręcznej na początku tego artykułu. Jeśli inny wątek w tym samym procesie pracuje na czymś zupełnie innym i zrzuca elementy o wysokim priorytecie do pamięci podręcznej, to gdy tylko .NET zdecyduje, że potrzebuje trochę pamięci, zacznie niszczyć niektóre elementy w pamięci podręcznej zgodnie z ich priorytety, najpierw niższe priorytety. Wszystkie udokumentowane tutaj przykłady dodawania elementów pamięci podręcznej używają domyślnego priorytetu, a nie wartości priorytetu NotRemovable, która zapobiega jego usunięciu w celu wyczyszczenia pamięci, ale nadal będzie usuwać go zgodnie z zasadami wygasania.
3. Klucz musi być ciągiem. Jeśli na przykład buforujesz rekordy danych, w których rekordy są wpisywane jako długie lub całkowite, musisz najpierw przekonwertować klucz na ciąg.
4. Składnia jest nieaktualna . To składnia .NET 1.0, brzydsza nawet niż ArrayList czy Hashtable. Nie ma tutaj żadnych typów ogólnych, nie ma interfejsu IDictionary <>. Nie ma metody Contains (), kolekcji Keys, żadnych standardowych zdarzeń; ma tylko metodę Get () oraz indeksator, który robi to samo co Get (), zwracając wartość null, jeśli nie ma dopasowania, a także Add (), Insert () (redundant?), Remove () i GetEnumerator () .
5. Ignoruje zasadę SUCHY podczas konfigurowania domyślnych zachowań związanych z wygasaniem / usuwaniem, abyś mógł o nich zapomnieć. Musisz wyraźnie powiedzieć pamięci podręcznej, w jaki sposób chcesz, aby dodawany element wygasał lub był usuwany za każdym razem, gdy dodajesz element.
6. Brak możliwości uzyskania dostępu do szczegółów buforowania elementu w pamięci podręcznej, takich jak znacznik czasu jego dodania. Hermetyzacja poszła tutaj trochę za daleko, utrudniając korzystanie z pamięci podręcznej, gdy w kodzie próbujesz określić, czy buforowany element powinien zostać unieważniony względem innego mechanizmu buforowania (np. Zbierania sesji), czy nie.
7. Zdarzenia usunięcia nie są ujawniane jako zdarzenia i należy je śledzić w momencie dodawania.
8. A jeśli nie powiedziałem tego wystarczająco dużo, firma Microsoft wyraźnie odradza to poza siecią. A jeśli jesteś przeklęty z .NET 1.1, nie powinieneś używać go z pewnością stabilności poza siecią, więc nie przejmuj się.

.NET 4.0's ObjectCache / MemoryCache

Firma Microsoft ostatecznie zaimplementowała abstrakcyjną klasę ObjectCache w najnowszej wersji platformy .NET Framework oraz implementację MemoryCache, która dziedziczy i implementuje ObjectCache na potrzeby pamięci w ustawieniach innych niż internetowe.

System.Runtime.Caching.ObjectCache znajduje się w zestawie System.Runtime.Caching.dll. Jest to klasa abstrakcyjna, która deklaruje zasadniczo te same interfejsy w stylu .NET 1.0, które można znaleźć w pamięci podręcznej ASP.NET. System.Runtime.Caching.MemoryCachejest implementacją ObjectCache w pamięci i jest bardzo podobna do pamięci podręcznej ASP.NET, z kilkoma zmianami.

Aby dodać element z ruchomym wygaśnięciem, Twój kod wyglądałby mniej więcej tak:

var config = new NameValueCollection();  
var cache = new MemoryCache("myMemCache", config);  
cache.Add(new CacheItem("a", "b"),  
    new CacheItemPolicy  
    {  
        Priority = CacheItemPriority.NotRemovable,  
        SlidingExpiration=TimeSpan.FromMinutes(30)  
    }); 

Plusy:

1. Jest wbudowany, a teraz obsługiwany i zalecany przez firmę Microsoft poza siecią.

2. W przeciwieństwie do pamięci podręcznej ASP.NET można utworzyć wystąpienie obiektu MemoryCache.

   Uwaga: nie musi to być statyczne, ale powinno być - takie jest zalecenie firmy Microsoft (patrz żółte Ostrzeżenie) .

3. W porównaniu z interfejsem pamięci podręcznej ASP.NET wprowadzono kilka drobnych ulepszeń, takich jak możliwość subskrybowania zdarzeń usuwania bez konieczności przebywania tam, gdy elementy zostały dodane, usunięto nadmiarową metodę Insert (), elementy można dodać za pomocą elementu CacheItem obiekt z inicjatorem, który definiuje strategię buforowania, i dodano Contains ().

Cons:

1. Nadal nie wzmacnia w pełni DRY. Z mojego niewielkiego doświadczenia wynika, że ​​nadal nie możesz raz ustawić ruchomego czasu wygaśnięcia TimeSpan i zapomnieć o tym. I szczerze mówiąc, chociaż zasada w powyższym przykładzie dodawania elementów jest bardziej czytelna, wymaga przerażającej szczegółowości.
2. Nadal nie ma klucza ogólnego; wymaga łańcucha jako klucza. Więc nie możesz przechowywać as long lub int, jeśli buforujesz rekordy danych, chyba że przekonwertujesz na ciąg.

Zrób to sam: Zbuduj siebie

W rzeczywistości utworzenie słownika buforującego, który wykonuje jawne lub przesuwane wygaśnięcie, jest całkiem proste. (Jest to o wiele trudniejsze, jeśli chcesz, aby elementy były automatycznie usuwane w celu wyczyszczenia pamięci). Oto wszystko, co musisz zrobić:

1. Utwórz klasę kontenera wartości o nazwie coś takiego jak Expiring lub Expiable, która zawierałaby wartość typu T, właściwość TimeStamp typu DateTime do przechowywania, gdy wartość została dodana do pamięci podręcznej, oraz TimeSpan, który wskazywałby, jak daleko od sygnatury czasowej, która pozycja powinna wygasnąć. W przypadku jawnego wygaśnięcia można po prostu ujawnić metodę ustawiającą właściwość, która ustawia TimeSpan z podaną datą odjętą przez znacznik czasu.
2. Utwórz klasę, nazwijmy ją ExpiableItemsDictionary, która implementuje IDictionary. Wolę, aby była to klasa ogólna ze zdefiniowaną przez konsumenta.
3. W klasie utworzonej w # 2 dodaj Dictionary> jako właściwość i nazwij ją InnerDictionary.
4. Implementacja, jeśli IDictionary w klasie utworzonej w # 2 powinna używać InnerDictionary do przechowywania elementów w pamięci podręcznej. Hermetyzacja spowodowałaby ukrycie szczegółów metody buforowania za pośrednictwem instancji typu utworzonego w punkcie 1 powyżej.
5. Upewnij się, że indeksator (this []), ContainsKey () itp. Ostrożnie usuwa elementy, które utraciły ważność, i usuwa je przed zwróceniem wartości. Zwróć wartość null w metodach pobierających, jeśli element został usunięty.
6. Użyj blokad wątków na wszystkich pobierających, ustawiających, ContainsKey (), a szczególnie podczas czyszczenia wygasłych elementów.
7. Podnieś wydarzenie, gdy przedmiot zostanie usunięty z powodu wygaśnięcia.
8. Dodaj instancję System.Threading.Timer i ustaw ją podczas inicjalizacji, aby automatycznie usuwała wygasłe elementy co 15 sekund. To jest to samo zachowanie, co pamięć podręczna ASP.NET.
9. Możesz chcieć dodać procedurę AddOrUpdate (), która wypycha przesuwający się termin wygaśnięcia, zastępując znacznik czasu w kontenerze elementu (instancja tracąca ważność), jeśli już istnieje.

Microsoft musi wspierać swoje oryginalne projekty, ponieważ jego baza użytkowników jest od nich zależna, ale to nie znaczy, że są to dobre projekty.

Plusy:

1. Masz pełną kontrolę nad wdrożeniem.
2. Może wzmocnić DRY , konfigurując domyślne zachowanie buforowania, a następnie po prostu upuszczając pary klucz / wartość bez deklarowania szczegółów buforowania za każdym razem, gdy dodajesz element.
3. Potrafi implementować nowoczesne interfejsy , a mianowicie IDictionary<K,T>. Dzięki temu jest znacznie łatwiejszy w użyciu, ponieważ jego interfejs jest bardziej przewidywalny jako interfejs słownika, a ponadto czyni go bardziej dostępnym dla pomocników i metod rozszerzających, które współpracują z IDictionary <>.
4. Szczegóły buforowania mogą być niezamknięte , na przykład przez ujawnienie InnerDictionary przez publiczną właściwość tylko do odczytu, co pozwala na pisanie jawnych testów jednostkowych w odniesieniu do strategii buforowania, a także rozszerzenie podstawowej implementacji buforowania o dodatkowe strategie buforowania, które na niej bazują.
5. Chociaż niekoniecznie jest to znajomy interfejs dla tych, którzy już przyzwyczaili się do składni pamięci podręcznej ASP.NET lub bloku aplikacji buforującej w stylu .NET 1.0, można zdefiniować interfejs tak, aby wyglądał tak, jak chcesz.
6. Może używać dowolnego typu kluczy. To jeden z powodów, dla których stworzono leki generyczne. Nie wszystko powinno być kluczowane za pomocą sznurka.

Cons:

1. Nie został wymyślony przez firmę Microsoft ani przez nią zatwierdzony , więc nie będzie miał takiej samej gwarancji jakości.
2. Zakładając, że tylko instrukcje, które opisałem powyżej, są zaimplementowane, nie usuwa "chcąc nie chcąc" pozycji do czyszczenia pamięci na zasadzie priorytetu (co i tak jest funkcją narzędziową w rogu pamięci podręcznej. KUP RAM, w której używałbyś pamięci podręcznej) RAM jest tani).

Spośród wszystkich czterech opcji preferuję to. Zaimplementowałem to podstawowe rozwiązanie buforowania. Jak dotąd wydaje się, że działa idealnie, nie ma żadnych znanych błędów (proszę o kontakt z komentarzami poniżej lub na jon-at-jondavis, jeśli są !!) i zamierzam używać go we wszystkich moich mniejszych projektach pobocznych, które wymagają podstawowe buforowanie. Oto ona:

Link do Github: https://github.com/kroimon/ExpiableItemDictionary

Stary link: ExpiableItemDictionary.zip

Godny uwagi: AppFabric, NoSQL, Et Al

Zwróć uwagę, że tytuł tego artykułu na blogu wskazuje „Proste buforowanie”, a nie „Pamięć podręczna o dużym obciążeniu”. Jeśli chcesz zająć się trudnymi sprawami, powinieneś przyjrzeć się dedykowanym rozwiązaniom skalowalnym.

MemoryCache jest tym, czym mówi, że jest, pamięcią podręczną przechowywaną w pamięci

HttpRuntime.Cache (patrz http://msdn.microsoft.com/en-us/library/system.web.httpruntime.cache(v=vs.100).aspx i http://msdn.microsoft.com/en- us / library / system.web.caching.cache.aspx ) zachowuje wszystko, co skonfigurujesz w swojej aplikacji.

zobacz na przykład „ASP.NET 4.0: Writing niestandardowych dostawców wyjściowej pamięci podręcznej” http://weblogs.asp.net/gunnarpeipman/archive/2009/11/19/asp-net-4-0-writing-custom-output-cache -providers.aspx

MemoryCache.Default może również służyć jako „most”, jeśli przeprowadzasz migrację klasycznej aplikacji ASP.NET MVC do ASP.NET Core, ponieważ w rdzeniu nie ma elementów „System.Web.Caching” i „HttpRuntime”.

Napisałem również mały test porównawczy, aby przechowywać boolelement 20000 razy (i inny test porównawczy, aby go odzyskać), a MemoryCache wydaje się być dwa razy wolniejszy (27 ms vs 13 ms - to łącznie dla wszystkich iteracji 20k), ale oba są superszybkie i to prawdopodobnie można zignorować.