Odpowiedzi:
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:
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.
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 .
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)
});
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) .
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 ().
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ć:
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.
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 <>.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
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ć.