Prawidłowe wdrożenie pamięci podręcznej w bibliotece klas do użytku w aplikacji asp.net

Question

Wdrażam pamięć podręczną w bibliotece klas, której używam w aplikacji asp.net.

Utworzono mój obiekt pamięci podręcznej jako wzorzec singleton ze statyczną metodą aktualizacji pamięci podręcznej, która tak naprawdę właśnie ładuje zmienną składową/właściwość z kolekcją danych, które wymagają buforowania (uzyskałem pewną logikę blokowania). Pomyślałem, że to dobry sposób, aby przejść ponieważ mogę tylko dostęp do moich danych poprzez wywołanie

MyCacheObject.Instance.MyDataCollection 

Tworzę nowy obiekt pamięci podręcznej do przechowywania całkiem sporą ilość danych, podzielona przez jakiś klucz. Mówię tylko, że tworzę nową pamięć podręczną, ale ta nie załaduje wszystkich danych naraz, ale raczej zapisze kolekcję dla każdego klucza, do którego dostęp uzyskałem.

MyOtherCacheObject.Instance.MyOtherDataCollection(indexkey) 

Tym razem pojawiło się pytanie o zbieranie śmieci. Ponieważ przechowuję ogromną ilość danych, czy nie byłoby to marnotrawstwem, gdyby nagle nastąpiło to? Ponieważ jest to pojedynczy wzorzec, nic nie gwarantuje, że dane pozostaną w pamięci podręcznej.

Moje pytanie brzmi: jaka jest najlepsza praktyka w implementowaniu pamięci podręcznej, aby poradzić sobie z tą sytuacją? Naprawdę nie podoba mi się ogromne, kompleksowe rozwiązanie tego problemu i wiem, że w System.Web jest buforowanie, ale wygląda na to, że jest trochę "wyłączone", ponieważ jest to po prostu biblioteka klasy, czy jak myślisz?

Answer 1

Moim zdaniem, najlepszym rozwiązaniem byłoby posiadać następujące cechy:

• Wykorzystuje dostępne usługi buforowania dostarczonych przez platformę stara się unikać pisania własnych.

• Nie łączy biblioteki klas z System.Web, aby warstwy były spójne.

• Ale jeśli biblioteka klas działa w aplikacji ASP.NET, rozwiązanie nie powinno wymagać włączenia kolejnej implementacji buforowania (na przykład Blok aplikacji aplikacji do buforowania biblioteki korporacyjnej), co wymaga dodatkowej konfiguracji i konfiguracji.

Używam strategii IoC, aby umożliwić bibliotece klas korzystanie z różnych implementacji buforowania, w oparciu o środowisko, w którym działa.

Załóżmy zdefiniować abstrakcyjne kontrakt buforowania jak:

public interface ICacheService 
{ 
    AddItem(...); 
} 

Można zapewnić realizację w oparciu o system.Web:

public AspNetBasedCacheService : ICacheService 
{ 
    AddItem(...) 
    { 
     // Implementation that uses the HttpContext.Cache object 
    } 
} 

I wtedy, że realizacja 'opublikowany' jako singleton. Zauważ, że różnica w porównaniu z oryginalnym podejściem polega na tym, że singleton jest tylko odwołaniem do implementacji opartej na pamięci podręcznej ASP.NET, zamiast pełnego "obiektu pamięci podręcznej".

public class ChacheServiceProvider 
{ 
    public static IChacheService Instance {get; set;} 

} 

Trzeba by zainicjować realizację chaching albo wykonując leniwe inicjowanie lub przy starcie aplikacji (w Global.asax.cs)

i każdy składnik domeny będzie w stanie korzystać z publikowanych usługę buforowania nie wiedząc, że jest zaimplementowany w oparciu o System.Web.

// inside your class library: 
IChacheService chache = CacheServiceProvider.Instance; 
cache.AddItem(...); 

Zgadzam się, że to nie jest chyba najprostsze rozwiązanie, ale mam nastawione na wykorzystanie realizacji cache ASP.NET bez kodu rozłączania oraz elastyczność poświęcenia.

Mam nadzieję, że dobrze zrozumiałem twoje pytanie.

Answer 2

Dane nie będą zbierane śmieci, o ile pamięć podręczna nadal zawiera odniesienie do niego.

Nie używaj też Singletonów.