Buforowanie w warstwie biznesowej a buforowanie w warstwie danych

Zawsze pracowałem nad projektami, w których buforowanie odbywało się w DAL, w zasadzie tylko wtedy, gdy masz wykonać połączenie z bazą danych, sprawdza, czy dane są już w pamięci podręcznej, a jeśli tak, to po prostu nie wykonuje połączenia i zamiast tego zwraca te dane.

Niedawno czytałem o buforowaniu w warstwie biznesowej, więc zasadniczo buforuję całe obiekty biznesowe. Zaletą, którą widzę od razu, jest znacznie lepszy czas reakcji.

Kiedy wolisz jeden od drugiego? oraz Czy buforowanie w warstwie biznesowej jest powszechną praktyką?

Jest to prawdopodobnie zbyt szeroki, aby uzyskać ostateczną odpowiedź. Osobiście uważam, że warstwa dostępu do danych jest lepszym miejscem do buforowania, po prostu dlatego, że ma być bardzo prosta - rekordy wchodzą i wychodzą i to wszystko.

Warstwa biznesowa implementuje wiele dodatkowych reguł o większej złożoności, dlatego lepiej jest, jeśli nie musi ona również zarządzać kwestiami dostępności poszczególnych obiektów oprócz obaw dotyczących spójności wielu obiektów w tej samej klasie (lub nawet tej samej metodzie) - to rażąco naruszać SRP.

(Oczywiście doszedłem do tego wglądu dopiero po tym, jak moje klasy usług stały się niemożliwe do opanowania, gdy próbowały jednocześnie buforować i konfigurować. Nie ma lepszego nauczyciela niż doświadczenie, ale cena jest na pewno wysoka).

Warstwy dostępu do danych i trwałości / przechowywania są nieodpartym naturalnym miejscem buforowania. Robią operacje we / wy, dzięki czemu są poręcznym i łatwym miejscem do wstawienia buforowania. Śmiem twierdzić, że prawie każda warstwa DAL lub warstwa trwałości, w miarę dojrzewania, otrzyma funkcję buforowania - jeśli nie zostanie zaprojektowana w ten sposób od samego początku.

Problem jest zamierzony . Warstwy DAL i trwałości radzą sobie z konstrukcjami stosunkowo niskiego poziomu - na przykład rekordami, tabelami, wierszami i blokami. Nie widzą obiektów „biznesowych” ani warstw aplikacji, ani nie mają wglądu w to, jak są używane na wyższych poziomach. Kiedy widzą, że kilka wierszy lub kilkanaście bloków jest odczytywanych lub zapisywanych, nie jest jasne, że reprezentują. „Konto Jones, które obecnie analizujemy” nie różni się niczym od „niektórych podstawowych danych referencyjnych stawek podatkowych, których aplikacja potrzebuje tylko raz, i do których nie będą się już odnosić”. Na tej warstwie dane to dane to dane.

Buforowanie w warstwie DAL / warstwa trwałości stwarza ryzyko, że siedzą tam „zimne” dane podatkowe, zajmując bezcelowo 12,2 MB pamięci podręcznej i zastępując niektóre informacje o koncie, które w rzeczywistości zostaną intensywnie wykorzystane w ciągu minuty. Nawet najlepsi menedżerowie pamięci podręcznej mają niewielką wiedzę na temat struktur danych i połączeń wyższego poziomu, a także mało wglądu w to, jakie operacje będą wkrótce dostępne, więc wracają do algorytmów zgadywania .

W przeciwieństwie do tego buforowanie w warstwie aplikacji lub biznesowej nie jest aż tak fajne. Wymaga wstawienia operacji zarządzania pamięcią podręczną lub wskazówek w środku innej logiki biznesowej, co sprawia, że ​​kod biznesowy jest bardziej złożony. Ale kompromis polega na tym, że mając większą wiedzę o strukturze danych na poziomie makro i nadchodzących operacjach, ma ona znacznie lepszą okazję do przybliżenia optymalnej wydajności buforowania („jasnowidz” lub „Bélády Min”).

To, czy wstawienie odpowiedzialności za zarządzanie pamięcią podręczną do kodu biznesowego / aplikacyjnego ma sens, wymaga oceny i będzie się różnić w zależności od aplikacji. W wielu przypadkach, chociaż wiadomo, że warstwy DAL / trwałości nie osiągną tego „idealnie”, kompromis polega na tym, że mogą wykonać całkiem dobrą robotę, że robią to w architekturze „czystej” i znacznie intensywniej testowalnej , a łapanie na niskim poziomie pozwala uniknąć złożoności kodu biznesowego / aplikacji.

Niższa złożoność zachęca do większej poprawności i niezawodności oraz krótszego czasu wprowadzania na rynek. Jest to często uważane za świetny kompromis - mniej doskonałe buforowanie, ale kod biznesowy o lepszej jakości, bardziej aktualny.

Buforowanie w DAL jest proste i proste

Twój DAL jest centralną warstwą dostępu do danych, co oznacza, że ​​każdy dostęp do danych może być kontrolowany za pośrednictwem tamtejszych klas. Ponieważ zarówno czytanie, jak i utrwalanie zachodzi na tych warstwach, równie łatwo można wyczyścić lub zaktualizować wpisy pamięci podręcznej w miarę zmian.

Buforowanie w firmie jest elastyczne

Buforowanie w firmie daje programistom elastyczność w określaniu, czy konkretne użycie obiektu skorzysta na buforowaniu. W zależności od struktury usług zaplecza aplikacji lub zautomatyzowanych procesów mogą zmieniać dane buforowane w innych częściach. Dzięki buforowaniu w przedsiębiorstwie programista może ustalić, czy określony obiekt biznesowy będzie mógł mieć nieaktualne dane i zwiększyć wydajność, czy też mieć najbardziej aktualny stan obiektu biznesowego kosztem wydajności.