Gdzie w kodzie należy zachować dane, które się nie zmieniają?

Question

Mam zdefiniowane modele na podstawie tabel w bazie danych. Teraz są pewne modele, których dane prawie się nie zmieniają. Na przykład kategorie produktów sprzedawane przez e-comm, miasta, w których wysyła produkty itp. Nie zmieniają się one często, a tym samym, aby uniknąć trafienia w db, są one obecnie zapisywane jako zmienne statyczne.

Pytanie, gdzie w kodzie powinny znajdować się te zmienne statyczne. Obecnie w klasie ProductCategory (która jest również reprezentacją modelu) zdefiniowana jest lista statyczna, która, jeśli jest pusta, wywołuje bazę danych i ładuje Kategorie produktów. Podobnie, klasa City ma podobną Listę statyczną i tak dalej.

Te statyczne listy są następnie używane w całej aplikacji. Myślałem o stworzeniu klasy o nazwie StaticData, a następnie zachowaniu wszystkich statycznych list w tej klasie. To jest teraz zamiast

ProductCategory.AllCategories.Find(p => p.Id = 2) 

będę miał

StaticData.AllProductCategories.Find(p => p.Id = 2) 

Która waszym zdaniem jest lepszym rozwiązaniem? Dążę również do testowalności i oddzielenia kodu od produkcji.

Czy istnieje lepszy sposób na ich osiągnięcie? Jak zrobić coś podobnego w swoim kodzie?

Answer 1

Jeśli jest wystarczająco statyczne być skompilowane do kodu, a nigdy musi się zmienić w czasie pracy, można użyć klasy statycznej, patrz na przykład wspólny wzorzec turning enums into classes.

Coś tak prawdopodobnie powinien pracować dobrze w swoim scenariuszu:

public class Vehicle 
{ 
    public static Vehicle Car = new Vehicle("Car"); 
    public static Vehicle MotorBike = new Vehicle("MotorBike"); 
    public static Vehicle PeopleMover = new Vehicle("PeopleMover"); 

    private Vehicle(string name) 
    { 
     this.name = name 
    } 
    private string name; 
} 

Korzystanie enum lub klasy z członków statycznych takich jak, że należy pomóc pozbyć się tych nieprzyjemnych magicznych liczb w kodzie, jak również, ale widząc, że składnia nie jest poprawna (brakujące =) założę, że to tylko przykładowy kod i nie wygląda jak nic w twojej prawdziwej bazie kodu.

Jeśli czasem pojawią się zmiany, a chcesz mieć listę kategorii w bazie danych, mogą być one mocno zbuforowane (jak prawie nigdy nie wygasają, ale są ręcznie unieważniane przy aktualizacji). W zależności od wielkości listy kategorii, rozważam umieszczenie całej kolekcji w jednej dużej pamięci podręcznej i wysłanie zapytania do obiektu z pamięci podręcznej dla poszczególnych kategorii, zamiast przechowywania osobnego wpisu w pamięci podręcznej dla każdego z nich.

Answer 2

Myślę, że powinieneś użyć Cache zamiast zmiennych statycznych.

Nie znam żadnych szczegółów na temat kodu, więc jeśli używasz repozytorium można zrobić coś takiego:

if [cache contains object or collection I need] 
{ 
    return [object or collection from cache] 
} 
else 
{ 
    [get object or collection from database] 
    [save object or collection in cache] 
    return [object or collection from database] 
} 

Następnie, jeśli zmienić buforowane podmioty trzeba znaleźć sposób, aby usunąć te buforowane wpisy, aby pobrać świeże dane z bazy danych.

Answer 3

Brak łatwej odpowiedzi. Masz kilka opcji i trzeba będzie rozważyć, który z nich jest lepszy dla swojej aplikacji:

• Możecie użyć jakiegoś bufora.

  Może zbyt skomplikowane, jeśli kategorie produktów nie zmieniają się często. Jest to idealne rozwiązanie, gdy często występują problemy z wydajnością (tysiące często czytanych kategorii) i często zmienia się kategoria produktów. Możesz korzystać z dowolnego systemu cache o otwartym kodzie źródłowym, ale to rozwiązanie może być bardziej skomplikowane.

• Możesz zakodować je jako Enum.

  Tylko dobrze, jeśli masz 100% pewności Kategorie produktów nigdy się nie zmienią ... nigdy!

• Możesz mieć klasę Lazy Singleton lub Static. (Moje preferowane)

  Najlepszą praktyką IMHO może być klasa Lazy Singleton lub static ProductCategory. Idealny, jeśli masz niewiele danych, które nie zmieniają się zbyt często, na przykład potencjalnie mogą ulec zmianie w wydaniu. Dostępne są dwa podejścia:

  Załaduj w Init: Zmienne statyczne powinny być przechowywane w warstwie logiki biznesowej jako stałe, w twoim przypadku możesz wstępnie wczytać Kategorie produktów przy uruchomieniu aplikacji i zachować je przez cały czas. W tym podejściu poświęcasz czas na ładowanie aplikacji.

  Załaduj przy pierwszym użyciu: Przy pierwszej próbie dostępu do kategorii sprawdź, czy są załadowane, czy nie. Jeśli nie, załaduj je. W tym podejściu poświęcasz czas w pierwszej chwili, w której potrzebujesz dostępu do Kategorii produktów.

  W każdym z tych dwóch podejść dane zostaną utracone po każdym uruchomieniu puli aplikacji, więc jeśli zwolnisz nową wersję, odświeżysz dane. W przypadku "awaryjnej" aktualizacji DB można zawsze później zrestartować pule aplikacji.