Skip to main content

Configurazione dinamica dei Bean

Configurazione dinamica dei Bean – FibersDependencyConfigurator

La classe FibersDependencyConfigurator ha il compito di definire dinamicamente i bean per diversi servizi del modulo fibers, in funzione del tipo di applicazione attualmente attiva (ad esempio: CD, AB, GP).

Questo approccio consente di gestire in modo centralizzato l’istanza dei servizi specializzati, evitando ridondanze e rendendo il codice più adattabile a contesti applicativi diversi.

Modalità di Configurazione

Il pattern utilizzato prevede la creazione di bean condizionati a runtime, in base al risultato di metodi statici della classe ServiceApplicationType, come:

ServiceApplicationType.isApplicationCD()
ServiceApplicationType.isApplicationAB()
ServiceApplicationType.isApplicationGP()

Ogni metodo @Bean restituisce una specifica implementazione in funzione del tipo applicativo rilevato.

Esempio

@Bean
public ServiceFibersLogical serviceFibersLogical() {
    if (ServiceApplicationType.isApplicationCD()) return new CdFibersLogicalService();
    if (ServiceApplicationType.isApplicationAB()) return new UndFibersLogicalService();
    if (ServiceApplicationType.isApplicationGP()) return new PPCFibersLogicalService();
    return null;
}

In questo esempio, il bean ServiceFibersLogical verrà istanziato con l’implementazione corrispondente al contesto applicativo. Se nessuna condizione è soddisfatta, viene restituito null. Alcune istanze dei vari bean hanno errori bloccanti in caso venga inserito una Stringa errata. La gestione della stringa errata è ancora in lavorazione.

Vantaggi del Pattern

  • Centralizzazione: la configurazione è mantenuta in un unico punto, semplificando la manutenzione.

  • Modularità: ogni implementazione è isolata e può evolvere indipendentemente.

  • Adattabilità: il sistema può comportarsi in modo diverso a seconda dell’ambiente, senza modificare il codice client.

Mancato utilizzo dei costruttori o di Lombok

In questa configurazione non vengono utilizzati costruttori con iniezione delle dipendenze né Lombok (es. @RequiredArgsConstructor) per una ragione specifica: le dipendenze vengono determinate dinamicamente a runtime, e quindi non possono essere definite al momento dell’iniezione via costruttore.

Pertanto, per iniettare i bean configurati dinamicamente, è necessario utilizzare @Autowired su campi o metodi, lasciando che sia Spring a gestire il binding effettivo in fase di esecuzione.

Questo vincolo è motivato dal fatto che:

  • Le implementazioni non sono note a compile-time.

  • Non è possibile annotare costruttori con più alternative dipendenti dal contesto.

  • L’uso di Lombok o dell’iniezione via costruttore richiede che tutte le dipendenze siano disponibili e univoche al momento dell’avvio, condizione non garantita in questo scenario.

  • Inoltre Lombok non gestisce correttamente i super costruttori.
No Comments
Back to top