Elo wszystkim,
mam taki serwis który ma dwie strategie promocji dla produktów. W klasie serwis wybieram tą strategię za pomocą @Qualifer w konstruktorze tego serwisu, ale teraz chciałbym to zmienić i móc wybierać strategie z pliku application.properties i takie pytanie jak się za to zabrać ?
link do serwisu
https://github.com/walczuk135/Zad/blob/master/src/main/java/com/service/rest/productservice/api/ProductService.java
@pawlo135 nie rozumiem co chcesz zrobić. Od czego zależy jaka implementacja/strategia ma być użyta?
Na bardzo pierwszy rzut oka to może jakiś factory bean który na podstawie tekstu zwróci odpowiednią implentację? Nawet bez Springa działa.
Możesz też wstrzyknąc wszystkie implementacje interfejsu i mieć jakiś matcher (np. jesli taka cena to taki itp)
Charles_Ray napisał(a):
@pawlo135 nie rozumiem co chcesz zrobić. Od czego zależy jaka implementacja/strategia ma być użyta?
Teraz chciałbym żeby była zależna od jakiejś wartości z pliku konfiguracyjnego application.properties albo .yaml itp. Da się to zrobić inaczej i lepiej ale głównie chodzi mi oto by móc wybrać właśnie z propertisów, takie ćwiczenie :0. I to musi być springowe podejście chyba właśnie chodzi o Conditional.
Najlepsze pliki konfiguracujne mają końcówke .java
. Ewentualnie .kt
lub .scala
. Reszta to przeważnie chore pomysły.
@jarekr000000: a co złego jest w trzymaniu np. tytułu emaila w propertisie albo scieżki do jakiegos katalogu?
Jeśli chodzi o tytuł emaila
- to faktycznie, choćby ze względu na i18 często ma sens trzymanie w jakimś propertiesie. Nie myślałem o takim typie konfigu.
Ale co do ścieżki do katalogu to już bardzo depends
. Ma sens zrobienie propertiesu jeśli to program standalone instalowany u użytkowników.
W typowej serwerówce nie widze sensu trzymania w jakiś tekstach:
- i tak najlepiej jak wszystkie serwery mają takie same konfiguracje - unikamy zamieszania,
- i tak najlepije jak zmiany przechodzą przez gita i CI/CD,
- i tak najlepioej jak nikt poza programistami w tym nie grzebie (ile ja godzin w życiu straciłem, bo ktoś z opsów coś przekonfigurował )
Rozwala mnie kult xml, propertiesów czy yamli gdzie wszystkie głupie parametry są wyniesione do zewnętrznego pliku, żeby łato można było zmienić
, a i tak najłatwiejszy sposób zmiany to
wcommitowanie zmiany do repo build i deploy zmienionego jara czy tam docker image :-)
@jarekr000000 nie no bez przesady, takie rzeczy jak np. URL do jakichś zewnętrznych serwisów, czy do bazy danych jak najbardziej pasuje mieć w properties, bo zwykle ten sam kod ma deploy na różne środowiska (prod, integracja, developerskie). Nigdy jeszcze nie spotkałem sie z pomysłem zęby takie rzeczy hardkodować a potem pushować do repo i budować aplikacje od nowa za każdym razem ...
Spotkałem się z konfiguracjami trzymanymi w osobnym repo, żeby mieć historię ich zmian i żeby wszystkie maszyny miały skąd pobrać "aktualny konfig", ale sama konfiguracja żyje generalnie dość niezależnie od aplikacji i nie ma za bardzo sensu ich trzymać w tym samym repo.
Ale ja mam te same urle na wszystkich środowiskach, nawet na lokalnej maszynie.
Są jakieś wyjątki, ale to raczej u firm gdzie infrastruktura jest z mezozoiku.
EDIT:
Nie chciałbym popadać w skrajność i pisać, że zawsze trzeba wszystko hardkowodać w kodzie.
Jakkolwiek, IMO ponad 90% rzeczy, które wodze w konfigach nie ma żadnego sensu. Głównie dlatego, że bez sensu tracimy type safety, robimy narzut na utrzymanie tego (mały ale jednak), a jeszcze końcowo i tak się robi pełny deploy takich yamli czy propertiesów razem z całą aplikacją).
Ten cały masterplan z hardkodowaniem wszystkiego i wrzucaniem wszystkiego do /etc/hosts czy coś w ten deseń rozbija się, kiedy masz zewnętrzne serwisy które działają inaczej w zależności od środowiska (z głowy - bramki płatności. Przy ostatniej z którą pracowałem instancja testowa oprócz standardowego hasła i loginu różniła się jeszcze urlc który trzeba było wysłać ze względu na topografię sieci).
Propertiesy nie są niczym złym i - jeśli o mnie chodzi - są po prostu troszkę (niewiele) czytelniejsze od konfiguracji trzymanych w kodzie.
@pawlo135: wracając do tematu to masz dwa podejścia. Jeśli możesz sobie pozwolić na podmianę i restart to chyba @ConditionalOnProperty: https://reflectoring.io/spring-boot-conditionals/
Jeśli ma być zmieniana w czasie działania to trzeba napisać proxy, ewentualnie synchronizowaną podmianę.