Używanie @ConfigurationProperties w Spring--

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:

@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:

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?

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.

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1