UWP i pamięć podręczna

0

Witam.

Muszę stworzyć do swojej aplikacji prosty system przechowywania danych w pamięci podręcznej. Zasada jest taka, mam zapytanie do API strony, odbieram odpowiedź w JSON i trzymam sobie te dane dla "dokładnie" tego samego zapytania przez powiedzmy 24 godziny. Zastanawiam się, czy nie ma jakiegoś gotowego i szybkiego mechanizmu, który mógłbym zastosować w aplikacji UWP.

Myślałem by po prostu by sprawdzać, czy zapytanie było już wykonywane, jeśli tak, to zapisać dane je pliku z datą zapisu i przy kolejnym identycznym zapytaniu odczytać najpierw datę, porównać z obecną, a potem jeśli nie minęły 24 godziny odczytać zawartość, a jeśli minęły pobrać dane na nowo, nadpisać i przetwarzać dalej. Nie wiem jednak, czy to rozwiązanie nie jest trochę zbyt przekombinowane.

Ktoś może coś doradzić?

EDIT: Dodaję info, że przechowywane dane, to maksymalnie kilka tysięcy wierszy w JSON na zapytanie i mechanizm ma służyć ograniczeniu wykonywania identycznych zapytań do serwera, bo po co zmuszać serwer do pracy nad zapytaniem przesłanym 5 minut temu, który da identyczne wyniki, a przecież musi je obliczyć. Nic nie stoi na przeszkodzie, by przechowywać odpowiedź w postaci pliku tekstowego.

0

Ja mniej więcej tak samo robię w swojej aplikacji - sprawdza daty zapisu plików i jeśli są starsze niż pewien określony czas to próbuje ponownie wykonać żądanie do API. Ale ja mam łatwiej o tyle, że faktycznie chodzi o pobieranie plików :-)

Ale możesz obejrzeć np. Akavache.

0

Ok, dzięki za info. Na razie zrobiłem tak, że zapisuję treść odpowiedzi z API jako plik .cache z unikalną nazwą i wykorzystując klasę ApplicationDataContainer tworzę sobie kontener, w którym zapisuję ustawienia pod kluczem, który stanowi zapytanie do API z dopiskiem _Date pod datę i _Name pod nazwę pliku . Potem sprawdzam datę i jak cache wygasł, to nadpisuję zawartość w pliku, jak nie wygasł, to po prostu wczytuje dane z pliku .cache. a po określonym czasie, np. tygodniu czyszczę kontener i katalog z cache, by nie zbierał się syf w nieskończoność, a datę do tej operacji trzymam też w kontenerze. Co prawda pewnie nie jest to idealne rozwiązanie, ale działa. Zamiast wykonywać identyczne zapytanie wczytuję pliki z kodem JSON i zawartość mogę odczytać bez problemu.

0
Wojciech Dudek napisał(a):

Ok, dzięki za info. Na razie zrobiłem tak, że zapisuję treść odpowiedzi z API jako plik .cache z unikalną nazwą...

Jak już tykasz plików, wpadasz w coś, co po mojemu jest "drugi przypadek", czyli server-level.

Podrzucam życzliwej uwadze amazonowski Redis i klient w C#. Multi purpose server (cache, grid, key-value, messaging), wart odnotowania w głowie

0

Nie bardzo rozumiem co miałeś na myśli. Myślę, że nie ma potrzeby zagłębiania się w chmurę jeśli to miałeś na myśli to: https://aws.amazon.com/elasticache/. To aplikacja instalowana na komputerze użytkownika, użytkownik może sobie odpowiedzi przechowywać u siebie. Wiadomo, że gdyby dane były w chmurze, to identyczne zapytania serwowane przez wielu użytkowników do chmury, to mniej zapytań do serwera z API, o którym była mowa, ale myślę, że na chwilę obecną zostanę przy tym co mam, a jak faktycznie zapytań będzie za dużo na limity API, to się pomyśli, chociaż raczej skorzystam z azure, bo mam tam konto. Pozdrawiam i dzięki za info.

1 użytkowników online, w tym zalogowanych: 0, gości: 1