Czy ten Spring to na pewno jest taki bee?

3

Cześć.
Od kilku lat pracuje jako java dev. Pamiętam jeszcze projekty w starszych wersjach Springa gdzie trzeba było konfigurować tone XMLi żeby wszystko chciało działać. Aktualnie Spring w mojej ocenie niesamowicie się zmienił i praca ze Spring Bootem + stackiem Springa jest bardziej przyjemna a community ogromne choć jak każda technologia ma ogrom zalet ale i też wad przez co nawet tutaj na forum często można spotkać opinie żeby szukać alternatyw. I super, bo to na pewno bardzo rozwojowe ale czy dobre w kontekście rozwijania projektów?

Jakiś czas temu chciałem napisać prototyp pewnej aplikacji i pomyślałem że bedzie to dobra okazja do nauki nowych technologi. Zamiast Springa postawiłem aplikację na alternatywnych technologiach, np.: Kotlin, Ktor (asynchroniczny serwer http), Kodein (IoC), JOOQ (dostęp do bazy danych).
Z jednej strony zauważyłem sporo zalet takiego podejścia. W przypadku JOOQ mam poczucie pełnej kontroli nad bazą danych (co w Spring Data czy w ogóle JPA nie zawsze było takie odczuwalne bo zawsze gdzieś ten element 'magi' w postaci wygenerowanych tabel czy zapytań pozostaje). Z drugiej jednak strony to co działało w Spring Data tutaj sprawia problemy, np część testów funkcyjnych uruchamiam na bazie H2 w pamięci. Problem w tym że w kodzie jak dodaje rekordy do bazy danych to potrzebuje je od razu zwrócić razem z id by dalej przetworzyć. Spring Data przy zapisie zawsze zwraca zapisaną encję a w jooq jest returning: https://www.jooq.org/doc/latest/manual/sql-building/sql-statements/insert-statement/insert-returning/
Niby spoko, też fajnie ale na H2 to nie działa, problem zauważony już od 2014 roku a nadal nie jest naprawiony: https://github.com/jOOQ/jOOQ/issues/3035
Efekt jest taki że testy padają i trzeba robić jakieś workaround'y.

Inna sprawa to pobieranie konfiguracji z plików yaml albo propierties. W Spring'u mamy @Value który wszystko robi za nas. Bez springa trzeba kombinować i ręcznie wszystko zaciągać - niby są biblioteki typu Snakeyaml i inne tego typu ale nie jest to już tak intuicyjne.

Generalnie przykładów mógłbym powielać więcej ale nie rozwodząc się już zbyt mocno przejdę do puenty.
Czy to nie jest trochę tak że Spring jak każdy inny framework ma swoje wady i zalety i pewne rzeczy może faktycznie robi dziwnie i z jednej strony możemy na niego narzekać ale prawda jest taka że nie ma aktualnie równie dobrej alternatywy?
Czy koszt wprowadzenia nowych technologii i zmaganie się z innymi problemami (które i tak przyjdą bo żadna technologia nie jest idealna) nie jest czasami większy?
Spring ma za sobą ogromne community, całkiem długą historię rozwoju, wypracowane dobre praktyki i mimo że też nie jest pozbawiony wad to na codzień produkcyjnie korzystamy właśnie z niego bo tak naprawdę porzucenie jego niewiele by zmieniło (zamienilibyśmy jedne problemy na inne)?

3

Ja np. nie mam zbyt dużego doświadczenia w Springu. Korzystając z niego zauważyłem, że najbardziej denerwuje mnie hibernate i JPA. Do prostych rzeczy super, cokolwiek więcej koszmar. W żadnym projekcie na prostych rzeczach się nie kończy. Dużo fajniej jest pobrać dane z bazy, załadować do POJO i na tym pisać sobie logikę wraz z unit testami. Spring Data z bazą noSql fajnie się to sprawdza. I mówię to jako wieloletni funboy Oracle, SQL i PL/SQL :)
Propertiesy w javie się łatwo ogarnia. Te w application.properties używam tylko dla właściwości frameworku.
Ja też robię sobie projekcik tak w ramach nauki, bazując na jednym ze swoich starych projektów. Tam gdzie logikę umieściłem w Javie to przenoszę sobie bardzo łatwo, kopiuj wklej, czasem poprawię trochę kod, dodam jakąś lambdę. Całą resztę muszę przepisywać. To zajmuje sporo czasu. Zrozumiałem, że logika nie powinna być zależna od technologii i frameworka.

Póki co uważam, że spring jest w miarę OK. Jednak tam gdzie mam kod zależny od niego (Security, WebClient, Thmyleaf do generowania maili) to mam go słabo przetestowanego, głównie przez to, że testy muszą czekać na wystartowanie contextu springa, a to kpina jest.

8

Często jadę po Springu, ale i pracuje z nim i próbuję robić czasem Spring z ludzką twarzą.
Złe są Beany i katastrofalne są aspekty.
Dziś widziałem przypadek gdzie jakiś security check (chyba!!) nie działał. Podobno, dlatego że adnotacje były na implementacji, a nie na interfejsie ... grubo. Jeszcze ten przypadek sprawdzam, może to bzdura, ale samo to, że nie można być pewnym czy działa Ci security to trochę straszne...

Żaden sensowny biznes nie powinien opierać się na aspektach!

Praktyka pokazuje, że nawet w bardzo klasycznym springu można użycie beanów i aspektów ostro minimalizować (np. ograniczyć się tylko do adnotacji Rest) resztę robić bibliotekami i springowymi templatami.

Najbardziej mi przykro jest jak widzę SpringBatch - naprawdę potrzebny tool i ma wiele fajnych rzeczy zrobionych (DSL do definiowania batchy jest naprawdę ok).
W praktyce w Spring batchu praktycznie nie da się nic zrobić bez beanów i to w ich najgorszej wersji czyli JobScope, TaskScope. Zmienne globalne, (statyczne) to pikuś w porównaniu do raka jakiego powodują (w kodzie) Scoped beany oparte o threadlocal.

Widzę systematyczną poprawę - WebFlux, czysto funkcyjny DSL bez fasolek to był duży krok naprzód. Projekty takie jak SpringFu pokazują jak można robić to co w SpringBoot tylko lepiej. Tylko chłopaki ze springa będą musieli jednego dnia oficjalnie powiedzieć, że Beany to ścierwo... Na razie trochę to marketingowo nie pasuje, po tylu latach psucia kodu beanami. Ale jest nadzieja, dawniej Spring był oparty o XML i w każdej książce o Springu były całe rozdziały o zaletach pisania w XML ( :-) )... jakoś udało się to wypchnąć i zakopać.

Mam już małe czyste aplikacje w Springu oparte o WebFlux (bez żadnego smierdzącego beana!)
Wada jest taka, że czasem przy WebFLuxie muszę wynajdować koło na nowo, zwykle się okazuje, że gdzieś tam jest, ale ostro zakopane w kodzie i nie ma dokumentacji.

Tak czy siak Spring jako zestaw bibliotek, tooli jest całkiem ok. Mogę tworzyć kod który na testach zachowuje się tak samo jak na produkcji i nie potrzebuje specjalnych testów integracyjnych, żeby sprawdzić czy aplikacja w ogóle wstanie. Czas frameworków już minął.

0

@jarekr000000: otóż nie sądze żeby beany miały zniknąc i nie sa one niczym złym jesli są stosowane zgodnie z rozsądkiem. Programowanie reaktywne nie jest odpowiedzią na wszystko. Co więcej, jest ich nawet więcej. Tylko trzeba wiedzieć kiedy z AOPa sie powinno korzystac a kiedy nie, akurat AOP sie przydaje do korzystania ułatiwien jakie dają frameworki np. zarządzanie transakcjami. I tu zadnej magii nie ma tylko trzeba wiedziec co sie robi.

0

Nie ukrywam @jarekr000000 że liczyłem na Twoją wypowiedź także dzięki za zaangażowanie ;)
Wracając jednak do Twojej wypowiedzi to właśnie dokładnie to samo obserwuje. Z jednej strony dostrzegamy te wszystkie wady i problemy które Spring ze sobą niesie ale z drugiej tak naprawdę nadal z niego korzystamy. Może nie w pełni ale nikt rewolucji w nowych projektach nie robi. We frontendach jak komuś nie pasuje Angular to bierze Reacta czy tam teraz Vue czy jakoś to mixuje a u nas jest trochę na zasadzie że plujemy na coś ale lepszej alternatywy i tak nie mamy więc musimy do tego pokornie wracać ;)

2

@eL tu może wazna uwaga co do korzystamy ze Springa. Ja korzystam przewaznie na zasadzie zgniłego kompromisu. Tam gdzie już ten Spring jest, albo tam gdzie zawczasu dostaję info, że ma być robione pod javowców / springowców. Spring WebFlux to dla mnie piękny trolling na architektów, którzy przypadkiem zatwierdzili Springa i już przeszli na make jar. Jest szansa sie prześlizgnąć (Ale mój kolega niedawno został przyłapany... :-) ).
W projektach gdzie mam troszkę bardziej rozwinięty team, mniejsze ograniczenia od klienta, albo programuje sam (tzw. małe szybkie strzały) nie ma w zasadzie miejsca dla Springa, ani nawet dla Javy, ani nawet dla Kotlina.
Wychodzi, że mam takie na mniej więcej 2 miesiące w roku. Do tego dochodzą jeszcze projekty hobbystyczne po godzinach / konferencyjne , ale tu faktycznie czasem używam Springa w ramach eksperymentów na wrogu :-)

0
jarekr000000 napisał(a):

Ja korzystam przewaznie na zasadzie zgniłego kompromisu.

Jasne, rozumiem ale jaki by ten kompromis nie był to prawie zawsze on jest. Nie ma czegoś takiego jak na froncie że skoro nie lubie i nie chcę Angulara to wezmę sobie np Vue i będze ok. Jak chcesz w Javie zrobić jakąś webówkę to praktycznie zawsze w mniejszym lub większym stopniu sprowadza się to do wykorzystania Springa (mimo narzekania).
Pytanie więc czy to wynika że nie ma lepszej alternatywy czy mimo tych wszystkich wad Spring jest dobrym wyborem?

Ps. Czemu akurat Scala? Też o niej kiedyś myślałem dość mocno (nawet założyłem fajnie rozwijający się temat ze Scalą który niestety ucichł https://4programmers.net/Forum/Off-Topic/260048-co_z_ta_scala ) ale mam wrażenie (biorąc pod uwagę liczbę ogłoszeń o pracę) że język mimo iż się rozwija to nie ma zbyt dużego zainteresowania. Wszyscy i tak klepią Java & Sprigng a Scalę traktują jako ciekawostkę (przynajmniej na polskim rynku to obserwuje).

EDIT
Sprawdziłem teraz ogłoszenia o pracę w różnych źródłach nie tylko w pl (m.in stackoverflow jobs) i w sumie jestem pod wrażeniem bo ogłoszeń jeśli o Scalę jest 2x więcej niż dla Kotlina (spodziewałem się że będzie podobna liczba). Co prawda Scala jest językiem starszym ale mimo wszystko jestem pod wrażeniem ;)

3
eL napisał(a):

Ps. Czemu akurat Scala? Też o niej kiedyś myślałem dość mocno (nawet założyłem fajnie rozwijający się temat ze Scalą który niestety ucichł https://4programmers.net/Forum/Off-Topic/260048-co_z_ta_scala ) ale mam wrażenie (biorąc pod uwagę liczbę ogłoszeń o pracę) że język mimo iż się rozwija to nie ma zbyt dużego zainteresowania. Wszyscy i tak klepią Java & Sprigng a Scalę traktują jako ciekawostkę (przynajmniej na polskim rynku to obserwuje).

Scala, bo można praktycznie pisać czysto. I oszczędza mi dużo problemów przy utrzymaniu refaktoringu - po prostu jak się skompiluje to już nawet nie muszę testować :-). Zresztą miałem takie kawałaki kodu w projektach, gdzie nawet szefa javowca do Scali przekonałem.

A to, że wszyscy piszą w Java & Spring to mi zwisa. Wszyscy to piszą w PHP, ale nadal nie jest to dla mnie argument. Poznałem każdy z tych języków . frameworków na tyle, żeby raczej starać się unikać.

2

Spring jest frameworkiem. Trzymaj swoją logikę biznesową z dala od frameworków. ( Na odległość jednego poziomu abstrakcji :) )

7

To ja zapytam, dlaczego? - OtoKamil 43 minuty temu

Dobre pytanie i jest na nie prosta odpowiedź:

Testy

Testowanie z frameworkiem zwykle jest wolne i upierdliwe.
W przypadku springa można też odpalać testy olewając kontekst springowy. Wtedy testy są szybkie i niewiele warte, bo krytyczne aspekty kodu nie są włączone.

Dla niedowiarków, którzy sądzą, że aspekty nie są istotną częścią logiki biznesowej mam konktrprzykład w postaci prawie każdego biznesu z jakim pracowałem, gdzie wymagania odnośnie security/ról były zawsze bardzo jasno i dokładnie określone w zadaniach. I weryfikowane.

Co więcej nawet takie tranzakcje bazodanowe okazują się w pewnych sytuacjach częścią logiki biznesowej. (np. jeśli mamy smutną historię z wymianą danych z innymi systemami przez db, albo jasno okreslone reguły na rollback/timeouty, powtórzenia operacji itp.).

Mniej ważne:
Są też inne, sytuacje, gdzie wychodzi że mieszanie logiki z frameworkiem to nie jest fajna sprawa: gruby refaktoring, ( np. rodzielanie na mikroserwisy), albo wymiana frameworka na nowszy model.
Nagle się okazuje, że po refaktoringu pewne kluczowe funkcje dają inne wartości, ale testy są nadal ok :-)

2

Ja też pomyślałem sobie o możliwości wymiany. Sposoby i zasady w jakie firmy prowadzą swoje biznesy zmieniają się rzadziej niż wersje frameworka i same frameworki. Jeżeli nie postawisz sobie warstwy abstrakcji możesz zbyt mocno uwiązać się z nimi samymi i zmiennymi kaprysami ich twórców. Dalsze czytanie: https://michalkulinski.blogspot.com/2019/01/zwiazani-z-frameworkiem2.html

0

Ciekaw jestem jak często wymienialiście framework. Ja pamiętam takie sytuacje ale w zasadzie zawsze (1 wyjątek) było to przy okazji przepisania systemu od nowa.
Zatem to dla mnie nie jest argument za wprowadzeniem dodatkowej komplikacji zwanej warstwą abstrakcji.
KISS i YAGNI - to jest najważniejsze :)

1

@magic_m: pisanie testów jest łatwiejsze (i są one szybsze) jak testujesz kod w samej javie niż jak testujesz kod+springa

0

Co by nie mowic to obecnie wszystko poza Springiem to troche folklor.

Jestem ciekaw tylko jak serverless i cloud wymusi pewne rzeczy np. https://quarkus.io/

0

Abstrahując od dobrego lub złego Springa - czemu beany i aspekty są złe? @jarekr000000

3

@Emdzej93 Bo zamiast stosować dobry design i poliformizm, bawisz się w technologie, które skanują Twoje klasy, modyfikują ich bytecode, polegają często na nieudokumentowanych częściach JDK. Wszystko w aspektach jest "stringly" typed. Jedna literówka w pointcut i leżysz.

Oczywiście wszystko ciężko testowalne. Bez Springa nie przetestujesz.

Jeszcze jakieś argumenty? :)

0
nie100sowny napisał(a):

@Emdzej93 Bo zamiast stosować dobry design i poliformizm, bawisz się w technologie, które skanują Twoje klasy, modyfikują ich bytecode, polegają często na nieudokumentowanych częściach JDK. Wszystko w aspektach jest "stringly" typed. Jedna literówka w pointcut i leżysz.

Oczywiście wszystko ciężko testowalne. Bez Springa nie przetestujesz.

Jeszcze jakieś argumenty? :)

Ja nie chciałem zabrzmieć jak jakiś obrońca beanów i aspektów, tylko miałem nadzieje usłyszeć jakieś historię od bardziej doświadczonych kolegów którzy się przy nich sparzyli, bądź poczytać jakiś ciekawy artykuł na ten temat ;)

0
nie100sowny napisał(a):

@Emdzej93 Bo zamiast stosować dobry design i poliformizm, bawisz się w technologie, które skanują Twoje klasy, modyfikują ich bytecode, polegają często na nieudokumentowanych częściach JDK. Wszystko w aspektach jest "stringly" typed. Jedna literówka w pointcut i leżysz.

Oczywiście wszystko ciężko testowalne. Bez Springa nie przetestujesz.

Jeszcze jakieś argumenty? :)

W jaki sposób korzystanie z beanów kłóci się z polimorfizmem? Zreszta własnie Spring ułatwia korzystanie z polimorfizmu bo możesz łatwo wstrzyknąc wszystkie implementnacje interfejsu.I jak ma się korzystanie z dobrego designu w sprzeczności z IoC? Chhyba że lubisz tracisz czas na ręczne rejestrowanie wszystkich zalezności. No to pozdro xD

8

Co jest złego w beanach i aspektach?
Aspekty:
zamiast mieć kod sprawdzany kompilatorem to polegamy na runtimowym wbogacaniu kulturowym,
W efekcie wywala się dopiero na produkcji.
Do tego aspekty te są bardzo **wrażliwe **na pozornie całkiem nieistotne zmiany w kodzie:

  • zmieniamy metodę na private -> boom, aspekty wysiadają,
  • wywołujemy z tego samego beana metodę - > boom.
  • wywołujemy asynchronizczne - boom
  • dorzucamy (lub nie) jednego jara -> boom (i to dopiero na produkcji).
  • itd. (ale testy działają ),

Beany to jak dla mnie tesknota za BASICIem, gdzie wszystko było globalne. Fakt, że czasem niezłe skróty dzięki temu można było zrobić :-) Takie beany to w zasadzie singletony , które można wszędzie wstrzyknać olewając zupełnie architekturę i zdrowy rozsądek. Do tego jeszcze dochodzą beany typu JobScope, RequestScope przy których nawet zmienne globalne czasem bledną... Bo to global per thread, w efekcie śledzenie jest jeszcze bardziej utrudnione.

Wersja TL;DR .
Nie po to Wanda nie chciała BASICA, żeby nasze dzieci babrały się w runtimowej magii i wywalały kod na produkcji.

0
scibi92 napisał(a):
nie100sowny napisał(a):

@Emdzej93 Bo zamiast stosować dobry design i poliformizm, bawisz się w technologie, które skanują Twoje klasy, modyfikują ich bytecode, polegają często na nieudokumentowanych częściach JDK. Wszystko w aspektach jest "stringly" typed. Jedna literówka w pointcut i leżysz.

Oczywiście wszystko ciężko testowalne. Bez Springa nie przetestujesz.

Jeszcze jakieś argumenty? :)

W jaki sposób korzystanie z beanów kłóci się z polimorfizmem? Zreszta własnie Spring ułatwia korzystanie z polimorfizmu bo możesz łatwo wstrzyknąc wszystkie implementnacje interfejsu.I jak ma się korzystanie z dobrego designu w sprzeczności z IoC? Chhyba że lubisz tracisz czas na ręczne rejestrowanie wszystkich zalezności. No to pozdro xD

Pisałem o aspektach...

2

Ja osobiście do pisania jakiś prototypów aplikacji czy MVP lubię użyć Spring Boota, bo wszystko od razu skonfigurowane itd. Do tego stosując podejście gdzie nie robisz każdej klasy beanem springowym tylko dzielisz sensownie projekt na moduły, gdzie w każdym jedynym beanem będzie klasa Fasady, czyli wejścia do modułu (poza springowymi implementacjami jakiś JpaRepository) możesz to łatwo testować w pamięci bez stawiania kontekstu. Testujesz sobie publiczne metody fasady (razem z corner casami), integracyjnie testujesz jedynie use casy (tylko te robiące Ci hajs). Dzięki temu możesz na testy powstrzykiwać jakieś InMemory implementacje repo na javowych kolekcjach (najlepiej Vavr) i swoje testy jednostkowe (testujesz fasady, więc zachowanie, a nie mokito) uruchamiasz bez Springa. W najlepszym wypadku masz konfigurację całej apki w pamięci. Problem zaczyna się jak chcesz mieć CQRS bo trzeba to jakoś obchodzić, no ale coś za coś.

W produkcyjnych projektach, jak robiłem w banku to faktycznie jaja z dynamic proxy czy thread local lub n+1 z JPA potrafią zrobić wtfy.

Sam kiedyś chciałem pisać aspekty, ale pomyśl sobie, że ktoś Twój kod potem czyta i chciałby go zrozumieć jak najszybciej. Beng !

0
jarekr000000 napisał(a):

Co jest złego w beanach i aspektach?
Aspekty:
zamiast mieć kod sprawdzany kompilatorem to polegamy na runtimowym wbogacaniu kulturowym,
W efekcie wywala się dopiero na produkcji.
Do tego aspekty te są bardzo **wrażliwe **na pozornie całkiem nieistotne zmiany w kodzie:

  • zmieniamy metodę na private -> boom, aspekty wysiadają,
  • wywołujemy z tego samego beana metodę - > boom.
  • wywołujemy asynchronizczne - boom
  • dorzucamy (lub nie) jednego jara -> boom (i to dopiero na produkcji).
  • itd. (ale testy działają ),

Beany to jak dla mnie tesknota za BASICIem, gdzie wszystko było globalne. Fakt, że czasem niezłe skróty dzięki temu można było zrobić :-) Takie beany to w zasadzie singletony , które można wszędzie wstrzyknać olewając zupełnie architekturę i zdrowy rozsądek. Do tego jeszcze dochodzą beany typu JobScope, RequestScope przy których nawet zmienne globalne czasem bledną... Bo to global per thread, w efekcie śledzenie jest jeszcze bardziej utrudnione.

Wersja TL;DR .
Nie po to Wanda nie chciała BASICA, żeby nasze dzieci babrały się w runtimowej magii i wywalały kod na produkcji.

Aspekty takie jak transakcje są wywoływane na metodach publicznych, a to że ktoś nie wie jak czegoś użyć to nie jest wina technologi. Zreszta ja też widziałem nieraz kod który sie kompilował, nie miał żadnej magi w postaci aspektów a nie działał, bo na przykład jakies pule watków z reaktora się kłóciły z pulą wątków od elastic searcha... Nie wspomiając już o programowaniu wielowątkowym z użyciem java.util.concurrency :D

1

@scibi92: Właśnie sam to napisałeś.

Chcemy by pisanie kodu biznesowego nie wyglądało jak pisanie w java.util.concurrent. Jak ktoś lubi się poruszać w kodzie jak po polu minowym to proszę bardzo.
Już wiem skąd biorą się te cytaty w niektórych korpo: "Hej, nie ruszajmy bo nie wiadomo!", "Po co ruszać, przecież działa". Właśnie stąd, że każdy refaktoring, ekstrakcja metody może CI wyłączyć transakcje.

0

@nie100sowny: Spring ma swoje wady, ale bardzo rzadko widziałem żeby coś z jego powodu się psuło. A mówinie "e przecież działa" odnosi się zazwyczaj do kijowej architektury, nieprzestrzegania SOLIDa itd. Pozbycie się Springa nie rozwiąże problemów jeśli robisz cudaczne klasy na 2000 linijek kodu.

3
scibi92 napisał(a):

@nie100sowny: Spring ma swoje wady, ale bardzo rzadko widziałem żeby coś z jego powodu się psuło. A mówinie "e przecież działa" odnosi się zazwyczaj do kijowej architektury, nieprzestrzegania SOLIDa itd. Pozbycie się Springa nie rozwiąże problemów jeśli robisz cudaczne klasy na 2000 linijek kodu.

Niestety Spring troche nieświadomie wspiera c**** kod, choćby dlatego że każdy junior-wanna-bee wie, że musi nauczyć się springa, więc czyta tutoriale springowe. Tutoriale springowe mają na celu pokazać dany feature czy nawet moduł springowy jak działa w uproszczonej formie, natomiast ludzie na tym się wzorują i myślą, że tak się pisze kod, potem się widzi w kodzie @Autowired na polu i jechane ;) Generalnie nie uważam Springa za złego, ale aspekty mają słabe wsparcie IDE, więc łatwo się na tym wywalić, jak ktoś przed nami stwierdził, że jebać pisanie kodu jak człowiek, on napisze aspekt. Spring rozwiązuje sporo problemów, sporo ułatwia, ale też dodaje nowe, pewnie każdy musiał powalczyć ze Springiem i wczytać się w jego internale, bo coś przestało działać ;)
Spring jest spoko, ale trzeba wiedzieć jak z niego korzystać, żeby sobie guza nie nabic

1

@hcubyc: a tu się zgodze. Generalnie sam wole unikać tworzenia swoich aspektów ( @jarekr000000 - serio!), na ogół korzystam tylko z tych Springowych - transactional i od security ew. cache. Sam zreszta pamietam jak sie kedyś wykłócałem że cache na pewnej metodzie nie powinien być zrobiony przez zastosowanie customowego aspectu tylko przez kompozycje :)

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