EJBs e DAOs utilizando pattern Singleton

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:

cara explica isso um pouco melhor...

estas classes não armazenam estado... não tem problema serem singleton...

uma dica: não crie este monte de getInstance(). Use um conteiner de IoC, por exemplo o spring.

leandroqbs wrote:cara explica isso um pouco melhor...

Olha minha arquiterura:

WEB ==> EJB ==> MANAGER ==> DAO

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.

marcelo_mococa wrote:
estas classes não armazenam estado... não tem problema serem singleton...

uma dica: não crie este monte de getInstance(). Use um conteiner de IoC, por exemplo o spring.

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í.

marcelo_mococa wrote:estas classes não armazenam estado... não tem problema serem singleton...

Tem sim!

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.

http://www.google.com/search?q=singletons+are+evil

GUJ Ranger Membro desde: 27/04/2005 18:52:49 Mensagens: 822 Offline

pcalcado wrote:

marcelo_mococa wrote:estas classes não armazenam estado... não tem problema serem singleton...

Tem sim!

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.

http://www.google.com/search?q=singletons+are+evil

Pergunta:

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

pcalcado wrote:

marcelo_mococa wrote:estas classes não armazenam estado... não tem problema serem singleton...

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.

ummm... qual seria a vantagem de se criar uma nova instância de uma classe que não mantêm nenhum estado?

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 ?

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.

Notícias, artigos e o maior fórum brasileiro sobre Java