Pro e contro dell'utilizzo di Singleton Pattern in DAL

Question

Ho chiesto di usare il modello singleton implementato DAL, ma penso che sia difficile mettere in comune le connessioni, usare transazioni..etc

Vorrei conoscere i pro e i contro e vorrei anche conoscere il modo migliore per mettere in comune le connessioni in quanto possono esserci più di 500 utenti simultanei per il sito che sto sviluppando.

DB Server è Oracle 10g.

DAL utilizza la libreria Enterprise 3.1

Answer 1

Il modello singleton è ottimo per un DAL: lo uso nella mia applicazione Web aziendale (centinaia di utenti e oltre 2.000 metodi in 20 classi alcune di singleton). Il pool di connessioni è gestito in modo ottimale da ado.net e dal server sql stesso. Se si desidera avere più tipi di server back-end, non è un problema. Anche con un modello singleton, probabilmente si desidera una classe di accesso ai dati centralizzata che gestisca le specifiche di effettuare effettivamente chiamate dirette al database (con parametri, nomi di testo / procedura, credenziali / stringa di connessione tutti passati).

Nella mia situazione, ogni metodo su un singolo corrisponde a 1: 1 con una procedura memorizzata nel mio database. Questo essenzialmente rende un front-end C # "". hook per ogni procedura memorizzata, in modo che possano essere chiamati quasi come il codice nativo C #, sintatticamente parlando. Rende le chiamate al DAL molto semplici. Ho più singoli a causa dell'enorme numero di SP in questione. Ogni SP ha un prefisso, come Sviluppo_, Finanziario_ o Organizzazione_ o altro. Quindi ho una classe singleton che corrisponde a ciascuna, come Sviluppo, Finanza o Organizzazione. Quindi sp Organization_ViewData sarebbe in C # un metodo chiamato ViewData su una classe singleton chiamata Organization.

Questo è solo un modo per farlo, ovviamente, ma ho scoperto che funziona molto bene con più sviluppatori e una grande quantità di codice negli ultimi sei anni. La cosa principale è che la coerenza è la chiave. Se un programmatore front-end sta guardando il nome di un metodo su uno dei tuoi broker singleton, questo dovrebbe dire loro esattamente dove sta andando alla fine del database. In questo modo se c'è un problema o se qualcuno deve cercare nel codice per cercare di capirlo, c'è meno traccia da fare.

Answer 2

La migliore pratica per il pool di connessioni è quella di non implementarlo da soli, ma piuttosto lasciare che il framework ADO.NET se ne occupi.

È possibile impostare le opzioni di pool di connessioni come parametri all'interno della stringa di connessione. Quindi, ogni connessione aperta con quella stringa verrà fornita dal pool di connessioni implementato e gestito dal framework. Quando chiudi o elimini OracleConnection, la connessione sottostante non viene distrutta ma tornerà al pool.

Questo è descritto qui:      http://msdn.microsoft.com/en-us/ biblioteca / ms254502.aspx

Informazioni sull'uso dei Singleton in generale: li ho usati per avvolgere il livello di accesso ai dati e ha sempre funzionato bene.

Nota che le transazioni si applicano solo a connessioni specifiche, non al database nel suo insieme. Questo significa che puoi avere diversi thread in esecuzione e ogni thread può leggere e scrivere nel database attraverso transazioni indipendenti, a condizione che ogni thread utilizzi un'istanza OracleConnection separata.

Answer 3

Non so di DAL ma il modello singleton è un ottimo modo per rendere i dati globali mantenendo una buona incapsulamento.

Answer 4

L'uso di un singleton per la factory di connessione al database nel DAL è abbastanza comune. Ti consente di collegare più facilmente diverse implementazioni della fabbrica senza cambiare molto codice. A molte persone non sembra piacere il modello singleton, ma penso che funzioni bene per questo tipo di cose.

Answer 5

Sono un po 'a disagio nell'usare i singleton nel caso di un DAL. E se volessi usare più di un back-end di database. Forse voglio usare MsSQL per le fatture ma Active Directory per l'autenticazione. O forse voglio usare MySQL per i post sul forum, ma PostgreSQL per il geo-clustering (più realistico per me, eh). Le interfacce Singleton potrebbero rendere il test dei livelli del database molto più impegnativo quando non riesco a passare una connessione di database finta al test.

Answer 6

Non credo che avrai differenze di prestazioni se usi un singleton o no, perché puoi sempre avere più thread in esecuzione sullo stesso metodo contemporaneamente. Se ti occupi di non avere campi interni che saranno condivisi in tutti i thread, tutto funzionerà bene.

Alla fine, la classe che gestisce il pool di connessioni deve essere thread-safe e finirai per creare alcuni blocchi che potrebbero influire sulle prestazioni, ma sono tutti necessari. (è realizzato internamente nel framework e non è comunque possibile modificarne il comportamento)

Se decidi di non usare un singleton, assicurati che le tue istanze DAL siano leggere perché questo potrebbe fare la differenza, ma di solito non lo è.

Nota: parlando dei pool di connessioni, l'unica cosa importante che devi fare è seguire la "apertura in ritardo, chiusura in anticipo" modello. Ciò significa, ritardare il più possibile l'apertura della connessione e chiuderla al più presto dopo aver fatto tutto il necessario.

Dopo aver costruito tutto il sistema usando questa regola magica, puoi giocare con i parametri della stringa di connessione per cambiare alcune opzioni del pool (dimensione iniziale, dimensione massima, ...)