Flusso di dati nell'iniezione delle dipendenze

4

Cosa abbiamo

  • Un modello di albero complesso memorizzato su più file XML
  • Classi di modelli Java che rappresentano il modello XML
    • Tutte le classi come POJO
    • Tutte le classi annotate con jaxb
  • jaxb per leggere i file XML
  • Un albero di classi di gestori
    • ciascun gestore è responsabile della gestione di un livello all'interno dell'albero del modello o di elementi specifici
    • le classi del gestore sono create usando guice come DI framework

Bit problematico

Alcuni gestori necessitano di dati elaborati in livelli analizzati in precedenza.

Esempio:

RootHandler
\- ChildHandler
   \- GrandChildHandler

In questo esempio il GrandChildHandler ha bisogno dei dati che il RootHandler ha calcolato. Al momento il codice sembra simile a questo:

# roothandler:
Data rootData = compute();
childHandler.handleLayer(rootData);

# childHandler:
Data childData = compute();
grandChildHandler.handleLayer(rootData, childData);

Domanda

Come dovremmo gestire questo flusso di dati nell'albero del gestore? È accettabile che i metodi chiamino "esplodere" più andiamo giù nell'albero?

Stavo anche pensando di memorizzare i dati del bambino in singleton, ma temo che non sarà intuitivo se questi dati cambiano a seconda di ogni calcolo da un childHandler.

Il framework delle dipendenze di Eclipse4 supporta l'iniezione sensibile al contesto. Pensi che sarebbe bello creare un oggetto di contesto che contenga tutti i dati tramandati e ogni gestore prende solo ciò di cui ha bisogno da lì?

Un'altra idea che avevamo era di separare dati localizzati e dati globali e quindi passare il globale attraverso metodi diversi. La mia paura qui è che l'esterno deve garantire che vengano impostati i dati globali più recenti.

C'è qualche soluzione standard per questo? Tutti i tutorial sulle iniezioni di dipendenza ignorano i progetti più grandi: (

    
posta Absurd-Mind 02.09.2016 - 10:47
fonte

1 risposta

1

Quando esci, vuoi mantenere le cose pulite, nel senso che è bello superare le dipendenze e mantenere il campo d'azione il più stretto possibile. Man mano che il tuo progetto cresce, potresti ritrovarti a passare un sacco di oggetti che non ti servono quasi mai e iniziano a contaminare le tue interfacce.

Il problema potrebbe essere che hai uno stato importante che hai ignorato.

Quando parli di classi di handler, producono risultati? Esiste un gestore della madre che attiva tutti i gestori e alla fine produce un risultato composto? Se è così, potresti voler avere una classe di stato con un riferimento statico alla struttura dei risultati. Quindi qualsiasi classe di gestore può accedere al "risultato principale" intermedio e trovare il convertitore di cui ha bisogno ogni volta che ne ha bisogno.

Se si tratta solo di alcuni casi, potresti stare meglio con un dizionario statico in ogni classe di gestore che produce i bit interessanti, in cui i bit interessanti vengono archiviati affinché i gestori dei figli possano accedervi in seguito. Dovresti eliminarli prima di iniziare la successiva "gestione dei master".

    
risposta data 02.09.2016 - 14:11
fonte

Leggi altre domande sui tag