Prós e contras do uso Pattern Singleton em DAL

Question

Eu pedi para usar padrão singleton implementada DAL, mas eu acho que é difícil reunir as conexões, uso transactions..etc

Eu gostaria de saber os prós e contras e também gostaria de saber a melhor maneira de reunir as conexões como pode haver mais de 500 usuários simultâneos para o site que estou desenvolvendo.

DB Server é Oracle 10g.

DAL usa biblioteca Empresa 3.1

Answer 1

O padrão Singleton é ótimo para uma DAL - Eu uso isso no meu próprio aplicativo corporativo web (centenas de usuários e mais de 2.000 métodos em 20 e algumas classes únicas). O pool de conexão é realmente tratado melhor por ado.net eo servidor SQL em si. Se você está querendo ter vários tipos de servidor back-end, isso não é um problema. Mesmo com um padrão Singleton, você provavelmente vai querer uma classe de acesso a dados centralizado que lida com as especificidades de realmente fazer chamadas diretas ao banco de dados (com parâmetros, nomes text / procedimento, credenciais / string de conexão todos passaram no).

Na minha situação, cada método em um único corresponde 1: 1 com um procedimento armazenado no meu banco de dados. Isso faz essencialmente um C # gancho "front end" para cada procedimento armazenado, de modo que eles podem ser chamados quase como código nativo C #, sintaticamente falando. Ele faz chamadas para a DAL muito simples. Eu tenho vários singletons por causa do grande número de SPs em questão. Cada SP tem um prefixo, como Development_, ou Financial_, ou ORGANIZATION_ ou qualquer outra coisa. Então eu tenho uma classe singleton que corresponde a cada, como Desenvolvimento, Financeiro, ou organização. Assim, o sp Organization_ViewData seria em C # ser um método chamado ViewData em uma única classe denominada Organização.

Isso é apenas uma maneira de fazê-lo, é claro, mas eu descobri que isso funcione muito bem com vários desenvolvedores e uma grande quantidade de código ao longo dos últimos seis anos. A principal coisa é que a consistência é a chave. Se um programador front-end está olhando para o nome de um método em um de seus corretores Singleton, que deve dizer-lhes exatamente onde ele está indo para o fim do banco de dados. Dessa forma, se há um problema, ou se alguém de ter que pesquisar através de código para tentar compreendê-lo, há menos de rastreamento que tem de ser feito.

Answer 2

A melhor prática para o pool de conexão é não implementá-lo, mas em vez deixe o quadro ADO.NET cuidar dela.

Você pode definir opções de conexão pooling como parâmetros dentro da seqüência de conexão. Então, a cada conexão que é aberto com essa seqüência será fornecido a partir do pool de conexão que é implementado e gerido pela estrutura. Quando você fechar ou alienar o OracleConnection, a conexão subjacente não é destruído, mas em vez disso, voltar para a piscina.

Esta é descrito aqui: http://msdn.microsoft.com/en-us/ biblioteca / ms254502.aspx

Sobre o uso de Singletons em geral:. Eu usei-os para quebrar a camada de acesso a dados, e sempre funcionou bem

Note que as transações só se aplicam a conexões específicas, e não o banco de dados como um todo. Isto significa que você pode ter vários threads em execução, e cada thread pode ler e escrever para o banco de dados por meio de operações independentes, proporcionando cada thread usa uma instância de OracleConnection separado.

Answer 3

Eu não sei sobre DAL mas o padrão Singleton é uma ótima maneira de fazer global de dados, mantendo um bom encapsulamento.

Answer 4

Usando um singleton para a fábrica de conexões de banco de dados na DAL é bastante comum. Ele permite que você mais facilmente conectar em diferentes implementações da fábrica sem mudar um monte de código. Um monte de pessoas não parecem como o padrão Singleton, mas acho que ele funciona ok para este tipo de coisa.

Answer 5

Eu sou um inquieto pouco sobre o uso de singletons no caso de uma DAL. E se eu quiser usar mais de um banco de dados backend. Talvez eu quero usar MsSQL para as facturas, mas Active Directory para autenticação. Ou talvez eu queira usar o MySQL para posts no fórum, mas PostgreSQL para geo-agrupamento (mais realista para mim, heh). Singleton Interfaces pode fazer testando as camadas de banco de dados muito mais difícil quando não posso passar uma conexão de dados de simulação para o teste.

Answer 6

Eu não acho que você vai ter diferenças de desempenho se você usar um singleton ou não, porque você ainda pode ter vários threads em execução no mesmo método ao mesmo tempo. Se você tomar cuidado de não ter campos internos que serão compartilhados em todos os tópicos, tudo vai funcionar bem.

No final, a classe que gerencia o pool de conexão precisa ser segmento seguro e você vai acabar fazendo alguns bloqueios que poderiam afetar o desempenho, mas todos eles são necessários. (É feita internamente no quadro, e você não pode mudá-lo de comportamento de qualquer maneira)

Se você decidir não usar um singleton, certifique-se de que suas instâncias DAL são lightweigth, porque isso pode fazer a diferença, mas geralmente não é.

Nota: falando sobre os pools de conexão, a única coisa importante que você deve tomar cuidado é de seguir o "aberto até tarde fechar mais cedo," padrão. Isso significa que, atrasar a abertura da conexão, tanto quanto possível, e fechá-lo o mais rápido possível depois que você fez tudo o que precisa com ele.

Depois de ter todo o sistema construído usando esta regra mágica, você pode jogar com os parâmetros seqüência de conexão para alterar algumas opções de piscina (tamanho inicial, tamanho máximo, ...)