Używanie @ConfigurationProperties w Spring--

Używanie @ConfigurationProperties w Spring--
NU
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 56
0

Mam aplikację w Kotlin + Spring Boot, w której staram się ograniczyć użycie beanów do minimum.
Niektóre ustawienia aplikacji chce móc łatwo zmieniać przy uruchamianiu dlatego używam @ConfigurationProperties. Przykład:

Kopiuj
@ConstructorBinding
@ConfigurationProperties(prefix = "myapp")
data class AllConfigurableProperties(val .....)


@Service
class TheOnlySpringService(properties: AllConfigurableProperties) {

    val notBean = Class1()

    fun someMethod() {
        notBean.someMethod()
        ...
    }

}


Class1 woła metodę Class2, Class2 metodę Class3....ClassN metodę Object1, Object1 metodę Object2 i tak do ObjectN.
Problem pojawia się gdy w ObjectN potrzebuję odczytać wartość z AllConfigurableProperties.
Jednym z rozwiązań jest zamiana wszystkich Object na Class i przekazywanie AllConfigurableProperties z TheOnlySpringService przez konstruktory aż do docelowego obiektu.
Tym sposobem za niedługo 90% klas będzie przyjmowało w konstruktorze AllConfigurableProperties tylko po to, żeby móc zmienić jakiś timeout/limit itp z command line'a.
Zastanawiam się nad alternatywnym rozwiązaniem i przychodzi mi do głowy coś takiego:

Kopiuj
object ConfigurationHolder {

    private lateinit var config: AllConfigurableProperties;

   fun getConfig() = config

   fun setConfig(conf: AllConfigurableProperties) {
       config = conf
   }

}

@Service
class TheOnlySpringService(properties: AllConfigurableProperties) {

   init {
       ConfigurationHolder.set(properties)
   }

   ....

}

Co myślicie o takim rozwiązaniu? Jest jakiś lepszy sposób od tych zaproponowanych powyżej?

jarekr000000
  • Rejestracja: dni
  • Ostatnio: dni
  • Lokalizacja: U krasnoludów - pod górą
  • Postów: 4712
1
  1. I wszystkie te klasy potrzebują konfiguracji ?
  2. Konstuktory są fajne
  3. Twój patern to po prostu Singleton - singletony to zwykle kiła (testowanie). Chyba, że singleton / object to po prostu zbiór funkcji (bez stanu).
  4. Mam taki pattern na DI (bo te fakto masz problem z DI)
    https://github.com/neeffect/kotlin-stones/blob/master/stones-server/src/main/kotlin/pl/setblack/kstones/stones/StoneModule.kt
    zobacz (i zobacz jak w testach to działa). Może Cię jakoś zainspiruje

Na tym można zrobić własnie ładne przekazywanie i inicjalizacjękonfiguracją tam gdzie trzeba.

NU
  • Rejestracja: dni
  • Ostatnio: dni
  • Postów: 56
0

W tym przypadku chodziło mi o singleton, który nie ma funkcji tylko niezmienialny stan ładowany przy starcie aplikacji. Z racji tego, że nie się dać @ConfigurationProperties na object, chciałem się posiłkować dodatkowym object (utrata niemutowalności stanu, ale możliwość wykorzystania w testach).
Dzięki @jarekr000000, chyba pozostanę jednak przy konstruktorach i spróbuję się zainspirować Twoim rozwiązaniem DI

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.