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
0
0
@pawlo135 nie rozumiem co chcesz zrobić. Od czego zależy jaka implementacja/strategia ma być użyta?
0
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)
0
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.
2
Najlepsze pliki konfiguracujne mają końcówke .java. Ewentualnie .kt lub .scala. Reszta to przeważnie chore pomysły.
0
@jarekr000000: a co złego jest w trzymaniu np. tytułu emaila w propertisie albo scieżki do jakiegos katalogu?
1
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 :-)
2
@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.
1
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ą).
0
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ę.