Livello di accesso ai dati con più backend e diversi design di database

Question

Sto iniziando un progetto e sto lottando con l'architettura per il nostro livello di accesso ai dati. Fondamentalmente sarà necessario interfacciarsi con più backend con diversi design di database.

Vorrei un DAL comune, che esegue una funzione comune in qualsiasi back-end. I backend hanno un codice univoco per l'inserimento, l'aggiornamento, ecc. Quindi aggiungere un Employee in 1 backend avrà un codice diverso in un altro.

Ho provato il modello di repository ma questo non si applica alla situazione. Ho finito con solo un metodo di modello di fabbrica, ma finirò per creare una fabbrica per ogni oggetto. Potrei forse creare solo 1 fabbrica, ma poi l'oggetto backend avrei centinaia di funzioni come "SaveEmployee", "SavePlan", ecc

In questo momento ho il seguente:

DAL 
    --> DAL.Backend1 
     --> Employee.Save(employee) 
     --> Plan.Save(plan) 
    --> DAL.Backend2 
     --> Employee.Save(employee) 
     --> Plan.Save(plan) 

Nel progetto DAL Ho un pattern Factory per ogni oggetto, Employee, Plan, per decidere quale oggetto DAL restituire ed eseguire contro.

Sono sicuro che questa non è la migliore architettura per questo, quindi mi chiedo se c'è un modello migliore da usare per risolvere il mio problema.

Answer 1

Abbiamo implementato questa funzionalità in uno dei nostri progetti. Non sono sicuro che sia la soluzione migliore, ma finora funziona per noi. Tuttavia, abbiamo uno strato DAO personalizzato basato su modelli CodeSmith che generano per noi le classi CRUD. In sostanza, abbiamo creato un singleton che rappresenta un broker di connessioni per tutti gli utenti. Quando l'utente esegue il login, seleziona il database a cui desidera connettersi (sebbene alcuni filtri IP restringano le loro opzioni, idealmente a 1). Il login memorizza un token di connessione con l'utente associato e la classe base per il livello DAO generato chiama il broker di connessione per recuperare la stringa di connessione appropriata. In questo modo ogni volta che un oggetto DAO viene chiamato, la stringa di connessione viene raccolta prima che l'oggetto DAO tenti di connettersi al DB.