Java Productivity vs Inne Frameworki/Języki

@scibi92: bo Spring jest najlepszy do testowania jedynie w urojeniach programistów i marketingowców, którzy jedyną alternatywę jaką widzieli to JavaEE. Wtedy jest lepszy :-). ( Nawet kamień u nogi jest lepszy więc nie dziwne).

A są dużo łatwiejsze i przyjemniejsze platformy do testowania np. Java.
W javie nie musisz podnosić żadnego kontekstu, nikt ci klas nie skanuje, nie wrzuca aspektów, interceptorów. itp.

A w Springu:

• albo testujesz ze Springowym kontekstem, skanowaniem klas aspektami, wolno i jeszcze trzeba to utrzymywać (nie jest to dramat, ale jednak).
• albo testujesz na mockach, co zwykle kończy się tym, że tak naprawdę dopisujesz kolejną suite testów Szczepanowi Faberowi (Mockito).

Ja wiem, że się da. Nawet widziałem dobre testy w Springowych projektach....

Jednakowoż jakoś każdy większy Springowy projekt do jakiego trafiam ma co najmniej grube wypaczenia w testach. (Ba, sam takie swego czasu porobiłem....).

Tak przy okazji - jak testujesz security? Jak testujesz perzystencję ?

Zresztą wchodzi na jesieni Spring 5. W Springu 5 będzie można programować w Springu nie uzywając Springa :-). Zapewne Josh Long zaprezentuje, że dzięki temu jest o wiele łatwiej testować (bo nie ma kontekstu i nic się samo nie wstrzykuje i nie ustawia). Ludzie to łykną. I dyskusja się skończy.

Juz to pokazywali na devoxx, ale niekoniecznie testowanie.

Spring jak wszystko ma swoje wady i wieloletni bagaz. Spring Web Reactive to jest pewna odpowiedz na potrzeby. Chociaz chcialbym tez cos podobnego nie w wersji reactive tez ;)

Jesli nie Spring to mamy inny problem. Wszyscy uzywali springa i czesto nic innego nie znaja i kolo sie zamyka.

No tak zrezygnujmy z AOP, piszmy ręcznie transakcje super wydajność

scibi92 napisał(a):

No tak zrezygnujmy z AOP, piszmy ręcznie transakcje super wydajność

z JOOQ nie wyglada to az tak zle ;)

Ale chyba mozna miec to nieco bardziej wysrodkowane:

Najwygodniej działa to z AOP -> piszesz @Transactional i jest git :)

scibi92 napisał(a):

No tak zrezygnujmy z AOP, piszmy ręcznie transakcje super wydajność

Dawno temu 4 ludków z Gang of Four spisało (bo wymyślono dużo wcześniej) wzorzec "Dekorator", który zresztą w Java SE jest użyty chociażby do Streamów. Każdy się tym podniecał jakie to przydatne, potem ktoś zgwałcił klasy cglibem albo jeszcze lepiej aspectJ i teraz panuje śmieszna teoria że bez tego nie da się żyć.

Teraz mamy programowanie funkcyjne i w ogóle można to uprościć do dekorowania jednej funkcji a nie podmiany całego obiektu bo 1 funkcja ma działać inaczej. Np. w kotlinie:

    transactional(transactionManager){
        //zrobione w transakcji
    }

I w czym to jest gorsze od założenia adnotacji? Tym że tracisz dodatkowo jedną linijkę na klamrę zamykającą? Za to zyskujesz jednolite działanie bez względu z jakiego miejsca wywołasz funkcję, nie masz narzutu przy tworzeniu obiektu i tworząc go przez new będzie działał tak samo.

Używam AOP, bo takie mam projekty i się dostosowuję. Mimo wszystko uważam to za bardzo nieudany eksperyment który jest ciągnięty nie wiadomo po co, skoro od kilku lat mamy w Javie lambdy.

scibi92 napisał(a):

Najwygodniej działa to z AOP -> piszesz @Transactional i jest git :)

Ale raczej nie ma powodu rezygnowac z tego jesli nie chcesz. A mozna wdrozyc inne zmiany ;)

@krzysiek050: z adnotacjami tracimy przede wszystkim wsparcie kompilatora a dowiadywanie sie o czyms w runtime potrafi byc bolesne.

Dziwne, ja nigdy nie miałem problemu z adnotacjami @ Transactional. Zaletą jest to że w ogóle nas to nie obchodzi w implementacji, i znacząco ułatwia pisanie testów jednostkowych

EDIT:
W sumie to rzeczywście jest troche utrudnienie z tym że runtimowo się dowiadujemy, ale cóż nic nie jest idealne :)

scibi92 napisał(a):

Dziwne, ja nigdy nie miałem problemu z adnotacjami @ Transactional. Zaletą jest to że w ogóle nas to nie obchodzi w implementacji, i znacząco ułatwia pisanie testów jednostkowych

EDIT:
W sumie to rzeczywście jest troche utrudnienie z tym że runtimowo się dowiadujemy, ale cóż nic nie jest idealne :)

@Transactional to jedno i w sumie to moglbym to zostawic.
Ale jest sporo innych adnotacji, które można byłoby z powodzeniem zastąpić kodem bez specjalnego bólu.

W JPA można popłynąć, na tyle, ze trzeba scrollować do nazwy klasy ;)

No to akurat racja, JPA bardzo dużo dziwactw różnych i mimo że generalnie lubię korzystać z JPA to jest to chyba najsłabiej zaprojektowanych modułów Javy Webowej ;)
Najdziwniejsze są te Criteria...

scibi92 napisał(a):

Najwygodniej działa to z AOP -> piszesz @Transactional i jest git :)

Jest git, do czasu aż przestaje być git - a wtedy zaczyna się brnięcie na wyścigi przez 700-stronowe książki o Hibernate (albo nie daj boże OpenJPA) żeby odkryć na jaką minę wpadliśmy tym razem

No ale my tu nie piszemy o JPA tylko o zarządzaniu transakcjami przez Springa :). JPA jest dosyć ciężkie niestety i to w sumie jeden ze słabszych elementów Javy Webowej

@jarekr000000:
Byłem na Twojej prezentacji na devoxx. Dobra była. I nawet mało kontrowersyjnie ;) Ale też sam widziałem dziwne rzeczy nieraz :D
Chociaż dla mnie prawda jest gdzies po środku, a w projektach często trzeba iść na jakis kompromis mimo wszystko. ;)

Spring Web Reactive + Kotlin
https://github.com/ssouris/petclinic-spring5-reactive

... wygląda zupełnie inaczej niż tradycyjny spring + java ;)

Krzywy Krawiec napisał(a):

Spring Web Reactive + Kotlin
https://github.com/ssouris/petclinic-spring5-reactive

... wygląda zupełnie inaczej niż tradycyjny spring + java ;)

serio?

            router {
                (accept(MediaType.APPLICATION_JSON) and "/api").nest {
                    "/owners".nest {
                        GET("/", ownersApiHandler::getOwners)
                        GET("/{id}", ownersApiHandler::getOwner)
                    }
                    "/pets".nest {
                        GET("/", petsApiHandler::getPets)
                        GET("/{id}", petsApiHandler::getPet)
                        GET("/{id}/visits", petsApiHandler::getPetVisits)
                    }
                }

ze skrajności w skrajność :) samo rejestrowanie beanów czy metod adnotacjami nie jest takie złe :p

W tym petclinic pewnie co nieco bym pozmienial.
Widze, ze jest tam zrobione RouterFunctions z DI, a w w sumie mozna i bez tego ;)

Może zapis jaki jest moze sie nie podobac.... ale ja widze miejsca gdzie to moze z kolei ulatwic.