Facade; até que ponto é vantajoso ou não utilizá-lo

Não há absolutamente nenhuma necessidade do façade ser um singleton. Não tem problema nenhum em instanciá-lo toda vez que for necessário.
Além disso, eu, particularmente, evito usar um façade para toda a camada de negócios porque acaba ficando uma classe inchada, com muitos métodos. Prefiro quebrá-lo em mini-façades que agrupam os métodos com responsabilidades em comum, e acabo chamando esse mini-façade de serviço. Esses serviços vão compor a camada de aplicação.

opa tnaires!

valeu ai pela resposta!
quer dizer entao que para cada requisicao vc cria um facade, e este facade não é unico, e sim dividido?
qual o critério de divisão que vc utiliza? por entidade?
Então após a GUI não existiria um ponto único de acesso (que seria uma classe facade unica) e sim vários pequenos pontos de acesso, correto?

valeu pelo post cara!
abs

Sim, para cada requisição eu crio uma instância do façade. Isso não traz maiores problemas, porque o escopo dessa instância é limitado. Se eu criar essa intância dentro do método doPost de um servlet, por exemplo, ao término da execução do método essa instância do façade já estará disponível para ser coletada pelo gc.

O critério que eu uso para dividir os façades é por funcionalidade, não necessariamente por entidade. Se eu tiver uma funcionalidade que engloba duas ou mais entidades - gerenciamento de pedidos, por exemplo, envolve cliente, vendedor, pedido, itens do pedido, etc - eu terei apenas um service para esta funcionalidade.

Mas é preciso verificar se há a necessidade de criar essa camada a mais na sua aplicação. Geralmente, eu a incluo quando preciso implementar coisas como controle transacional, logging, etc, ou quando minha aplicação terá mais de uma view simultânea. Se for um simples crud, chamo o EntityManager mesmo direto do controle e pronto.

entendo…

bem, deixe-me descrever um pouco da minha aplicação para deixarmos as coisas mais claras.:

• minha aplicacao é dividida em módulos.
• cada módulo possui um facade
• a GUI, feita com struts, comunica-se direto com uma classe que eu chamei de Proxy, que tem a responsabilidade de iniciar e fechar transacao e de delegar a responsabilidade da requisicao, isto é, ele chama o facade do modulo responsavel pela chamada.
• Todos os facades e o Proxy sao singleton

bem, esta é a cara do sistema a grosso modo.

valeu

Mas há algum motivo especial por você ter utilizado singleton no projeto? Perguntando de outra forma, qual o problema que você teria se você não restringisse a instanciação dessas classes?

Seu proxy e facades são thread-safe ou contêm estado? (contêm tem acento, ainda?)

Se você não tem estado nos facades (e não vejo por que teria) então pode acessá-los simultaneamente, logo não há problemas de performance. O problema acontece se você tem que sincronizar tudo. Aí a performance desaba.

opa galera…

valeu ai tb rubinelli pelo post!
bem, acho que já deu pra desmistificar em mim que facade tem que ser singleton.
vou tentar outras abordagens…

ouvi um pessoal falando sobre Web Centric + EJB Centric e fachadas EJB’s Stateless. Nunca ouvi falar nisso ai
alguém sabe do q se trata ou se tem algo a ver com o nosso tópico em discussão?

valeu

danilo.dct:

bem, acho que já deu pra desmistificar em mim que facade tem que ser singleton. vou tentar outras abordagens...

public class Facade {
    private static Facade instance = new Facade();

    private Facade() {
        
    }

    public static Facade getInstance() {
        return instance;
    }
}

public class Facade {
    /** Pode até manter o construtor privado, pra garantir que
     *  só seja possível instanciar a classe a partir do método
     *  getInstance().
     */
    private Facade() {

    }

    public static Facade getInstance() {
        return new Facade();
    }
}

opa tnaires…

filé! é isso msm… valeu!

ja ouvi falar que utilizar facade (em um sistema grande) singleton gera problema de concorrencia, enquanto fachadas não singleton resolve o problema de concorrência e enfileiramento de threads, porém gera o problema de alocação de memória. Diz-se ainda que com o tempo, e o crescimento, facilmente chega-se a um “No Memory Available”.

procede?

abs

Outras pessoas aqui no fórum já expuseram as desvantagens de usar singleton bem melhor do que eu um dia poderia expor. Tentei localizar um post antigo do usuário Luca em que ele listava essas desvantagens, mas a pesquisa do fórum só retorna posts recentes… Estranho.

Quanto ao problema de memória… Acho meio improvável de acontecer. Como falei em um post anterior neste tópico, geralmente criamos uma instância de um façade para usar dentro do escopo de um método. Quando o método termina sua execução, essa instância fica disponível para ser coletada. Mas não tenho autoridade suficiente para falar sobre isso, pois nunca trabalhei com um sistema que realmente exigisse muito da máquina. Talvez algum outro usuário que tenha lidado com problemas de escalabilidade possa dar uma opinião mais sólida.