Come progettare DAO quando l'origine dati varia dinamicamente

Question

Di solito quando si definisce un DAO, si avrebbe un setter per l'origine dati sull'oggetto DAO. Il mio problema è che la nostra origine dati varia dinamicamente in base alla richiesta al server. cioè ogni richiesta può accedere a diversi istanza del database.

La richiesta contiene proprietà logiche, che in seguito possono essere utilizzati per recuperare la connessione al DB della richiesta.

Così, quando la dipendenza iniettando il DAO all'oggetto logica di business, ho bisogno di un modo per impostare le proprietà del DAO in fase di esecuzione (non la configurazione di tempo).

Una soluzione consiste nel memorizzare l'origine dati sul filo locale, ma io in realtà non piace fare scherzi con le variabili locali filo.

Un'altra opzione è quella di avere un metodo di inizializzazione sull'oggetto logica di business che prevede l'inizializzazione sul DAO con le proprietà di richiesta.

Credo che sia un problema comune, si può suggerire una soluzione comune?

Answer 1

Sembra che il tuo problema è che si sta creando una singola istanza di DAO per la vostra applicazione. Si sia necessario creare un'istanza separata per ogni origine dati (magari facendo qualche tipo di controllo dao di gestire tutto per voi) o, eventualmente, consentire ai metodi nel tuo DAO per essere statico e trasmettere tutte le informazioni sulle modalità di connessione all'origine dati insieme i dati che persistono in ogni metodo.

Answer 2

Il tuo problema è un po 'di confusione. Avere un accesso DAO più origini dati diverse sembrerebbe essere un incubo di manutenzione. Di conseguenza, è necessario definire un'unica interfaccia DAO che contiene tutti i metodi che si desidera chiamare. Per ogni database ci si sta connettendo vorrei costruire una nuova classe che implementa l'interfaccia DAO. Questo permette di avere implementazioni multiple. Vorrei quindi memorizzare queste implementazioni (ciascuno che ha una sua origine dati) in una mappa (java.util.Map), utilizzando le "proprietà logiche" come la chiave per la mappa. Dal momento che tutte le implementazioni DAO implementano l'interfaccia si sarà in grado di gettarli all'interfaccia e li usa in modo intercambiabile. Sul vostro oggetto di business, si dovrebbe iniettare la Mappa di implementazioni DAO. Spero che questo aiuta il vostro disegno.

Answer 3

Si consiglia di guardare in questa classe:

http: //static.springframework.org/spring/docs/2.5.x/api/org/springframework/jdbc/datasource/lookup/AbstractRoutingDataSource.html

In questo modo sarà più facile per i vostri oggetti del servizio e gli oggetti di accesso ai dati di essere ignorante che qualsiasi nozione di origini dati dinamici esiste.

In genere avresti bisogno di implementare un filtro servlet e utilizzare un ThreadLocal in modo che l'attuazione DataSourceLookup usata da AbstractRoutingDataSource può facilmente accedere ai parametri della richiesta che dettano che DataSource viene restituito. Se davvero si vuole evitare che, si potrebbe implementare un filtro servlet, che imposta le proprietà su un fagiolo richiesta con ambito e iniettare che fagiolo nell'attuazione DataSourceLookup che hai scritto. fagioli Richiesta con ambito usano ancora un ThreadLocal nella loro attuazione, ma almeno questo modo è impl di primavera, non la tua, e non c'è bisogno di preoccuparsi. :)

approccio simile è dettagliata in questo blog del team di Primavera:

http://blog.springsource.com/2007/01 / 23 / dinamico-datasource-routing /

Answer 4

Ho avuto un problema del genere su un progetto client / server. progetti client e server era condividere interfacce Dao. E quando ho usato per fare un'operazione di database ho dovuto selezionare implementazione Dao adatto. La mia soluzione era così:

IVehicleDao vehicleDao =daoFactory.Get<IVehicleDao>(parameters);
vehicleDao.doSomething();

Get dao dalla fabbrica passando parameters.Inside Dao fabbrica decidere quale implementazione Dao per tornare ..

Answer 5

L'ho già fatto questo. È necessario creare un DAO ogni classe, e nel l'ambito della DAO è necessario passare il DataSource e, infine, un controller di classe dove si fa vocazione dinamica a DAO.