Já me falaram uma vez que não é recomendado utilizar o padrão Singleton para implementar DAO ou camada logo abaixo de EJBs. Tem um projeto aqui que tem esse arquitetura. Estou com alguns problemas de leak na aplicação mas não acho que isso seja o problema.
Mas queria saber o motivo de não ser recomendado a utilização de Singleton em DAO e na camada de negocio aqui chamada de Manager ou AppServices. Preciso de argumentos para conseguir mudar essa arquitetura aqui.
Só para tentar ilistrar melhor vou colocar uma parte do código para ver se vocês entendem:
public class MeuBean implements SessionBean {
public void metado() {
MeuManager.getInstance().metado();
}
}
public class MeuManager {
public void metado() {
MeuDao.getInstance().metado();
}
}
Sendo que o manager e o dao são singletons. Já ouvi falar que isso não é uma boa prática. Mas não estou conseguindo detectar o problema, sendo que minha aplicação está com problemas de performance e leak de memória, queria saber qual o problema de utilizar essa arquitetura. Como já vou ter que fazer um tunning na aplicação eu mudaria essa arquitetura se realmente isso for um problema.
Vlw pela dica do spring, realmente facilitaria um pouco.
Já tranguilizei um pouco em relação a essa arquitetura.
vlw pela ajuda.
Se alguém ver possíveis problemas relacionados a essa arquitetura posta aí.
Só porque uma classe não teme stado não quer dizer que ela deva ser ou tire benefícios de ser Singleton. Um Singleton deve ser utilizado apenas quando somente uma instância pode ser criada.
Fazendo uso de Singletond esta maneira você está criando uma variável global, procure toda a literatura sobre variáveis globais e seus problemas e ela pode ser aplicada neste caso.
Fora que fazendo uso pesado de métodos estáticos você perde testabilidade (faça um teste unitário usando um DAO mock por favor), além de que o uso de classes de negócio seme stado provavelmente está relacionado a programação procedural, especialmente programação com BO/VO.
Só porque uma classe não teme stado não quer dizer que ela deva ser ou tire benefícios de ser Singleton. Um Singleton deve ser utilizado apenas quando somente uma instância pode ser criada.
Fazendo uso de Singletond esta maneira você está criando uma variável global, procure toda a literatura sobre variáveis globais e seus problemas e ela pode ser aplicada neste caso.
Fora que fazendo uso pesado de métodos estáticos você perde testabilidade (faça um teste unitário usando um DAO mock por favor), além de que o uso de classes de negócio seme stado provavelmente está relacionado a programação procedural, especialmente programação com BO/VO.
Pelo que entendi num artigo que lí, é necessário evitar singletons porque muitas vezes ele não economiza quase nada de rescursos (a nível de hardware) e caso eu tenha que limitar a quantodade de objetos daquela instância, deveria utilizar uma factory… correto ?
Então teoricamente o getInstance() nunca deve existir ?
Só porque uma classe não teme stado não quer dizer que ela deva ser ou tire benefícios de ser Singleton. Um Singleton deve ser utilizado apenas quando somente uma instância pode ser criada.
[/quote]
ummm… qual seria a vantagem de se criar uma nova instância de uma classe que não mantêm nenhum estado?
Singleton economiza recursos sim… o problema é ficar criando um monte de getInstace()… Por isso que é legal usar um conteiner de IoC como o spring que já faz o papel do factory controlando os singletons.