Wpis z mikrobloga

@BOT_Ethan: Z doświadczenia wiem, że nigdy nie kończy się to dobrze. Potem trzeba jakieś cudaczne filtry robić żeby wyłączyć podpakiety, robią się dziwne zależności cykliczne etc. Najlepiej robić jakieś tematyczne Configi w stylu DatabaseConfig, SecurityConfig, JsonConfig itp i w nich robić beany przez normalne wywołanie konstruktora. Najgorsze są klasy z pustym konstruktorem i 50 polami @Autowired.
  • Odpowiedz
@goompas: Pozwolisz że się nie zgodzę. Zawsze zaczyna się na skanie na com.super.szczegolowy.pakiet.i.wszystko.fajnie. Potem robi się com.super i kończysz z klasami na 20 pól Autowired, IDE nie potrafiącym Ci powiedzieć czy klasa jest instancjonowana (w końcu wszystko idzie przez refleksję), zależnościami w kółko i ogólnym bajzlem.
  • Odpowiedz
@ania-nowak1231: spokojnie to nie będzie wielki projekt, tak sobie sprawdzam różne rzeczy ale faktycznie do wszystkiego postaram się pisać config, (W sensie mongo oddzielę od reszty ale to rzy okazji ;))
  • Odpowiedz
@BOT_Ethan: Normalnie robisz tematyczne @Configuration klasy, w których robisz sobie metody z @Bean zwracające twoje beany i wszystko ładnie ręcznie wstrzykujesz. Potem bez problemu widać co i gdzie idzie, jest mniej refleksji w kodzie i IMO zdecydowanie porządniej to działa.

Konfigi możesz bez problemu importować do uber-konfigów, etc.
  • Odpowiedz
@ania-nowak1231: @BOT_Ethan: ja tam wolę jednak convention over configuration. Jeżeli ktoś nie ogarnia podziału zakresów odpowiedzialności w aplikacji to nie jest problem związany z biblioteką, ale programistą.
Od tego żeby było przejrzyste i było widać gdzie co jest mam IDE.
Używamy takiego podejścia w kilkudziesięciu żywych projektach i nigdy nie było problemów o których piszesz.
Oczywiście, że można zrobić zależności cykliczne między zakresami, ale to świadczy o nie
  • Odpowiedz