Quais são as vantagens e desvantagens do padrão Session Façade núcleo J2EE?

Question

Quais são as vantagens e desvantagens do padrão Session Façade núcleo J2EE?

O que são as premissas por trás dele?

São estes pressupostos válidos em um ambiente particular?

Answer 1

Session Facade é um padrão fantástico - é realmente uma versão específica do padrão de negócios Fachada. A idéia é amarrar a funcionalidade de negócios em pacotes discretos - como TransferMoney (), Saque (), Depósito () ... De modo que seu código UI está acessando coisas em termos de operações de negócios em vez de acesso de baixo nível de dados ou outros detalhes que não deveria ter que se preocupar com.

Especificamente com a fachada da sessão - você usar um EJB Session para atuar como a fachada de negócios - o que é bom porque então você pode tirar proveito de todos os serviços J2EE (autenticação / autorização, transações, etc) ...

Espero que ajude ...

Answer 2

A principal vantagem do padrão Session Facade é que você pode dividir uma aplicação J2EE em grupos lógicos de funcionalidade de negócios. Uma fachada de sessão será chamado por um POJO a partir da interface do usuário (ou seja, um Business Delegate), e ter referências às Data Access Objects. Por exemplo. um PersonSessionFacade seria chamado pelo PersonBusinessDelegate e então ele poderia chamar o PessoaDAO. Os métodos no PersonSessionFacade será, no mínimo, seguir o padrão CRUD (Criar, recuperar, atualizar e excluir).

Normalmente, a maioria das Fachadas de sessão são implementados como EJBs de sessão sem estado. Ou se você estiver em terra Primavera usando AOP para transações, você pode criar um POJO serviço que pode ser todos os pontos de juntar-se para o seu gerenciador de transações.

Outra vantagem do padrão SessionFacade é que qualquer desenvolvedor J2EE com um mínimo de experiência vai entender imediatamente.

As desvantagens do padrão SessionFacade: assume uma arquitetura empresarial específico que é limitada pelos limites da especificação J2EE 1.4 (veja os livros de Rod Johnson para essas críticas). A desvantagem mais prejudicial é que ele é mais complicado do que o necessário. Na maioria empresa web aplicativos, você precisará de um servlet container, ea maior parte do estresse em uma aplicação web estará no nível que alças HttpRequests ou acesso ao banco. Consequentemente, não parece valer a pena para implantar o servlet container em um espaço de processo separado do container EJB. Ou seja, chamadas remotas para EJBs criar mais dor do que ganho.

Answer 3

Rod Johnson afirma que a principal razão que você gostaria de usar uma fachada de sessão é se você está fazendo Container Managed transações - (. Como Spring) que não são necessárias com estruturas mais modernas

Ele diz que se você tiver lógica de negócios - colocá-lo no POJO. (Que eu concordo com - Eu acho que é uma abordagem mais orientada a objetos - em vez de implementar um EJB de sessão.) http://forum.springframework.org/showthread.php?t=18155

Happy ouvir argumentos contrastantes.

Answer 4

Parece que sempre que você fala sobre J2EE qualquer coisa relacionada - há sempre um monte de suposições por trás das cenas - que as pessoas assumem uma forma ou de outra - que leva a confusão. (Eu provavelmente poderia ter feito a pergunta mais clara também.)

Assumindo (a) nós queremos usar operações geridas recipiente em sentido estrito através da especificação EJB, em seguida,

fachadas de sessão são uma boa idéia - porque eles abstrair as transações de banco de dados de baixo nível para ser capaz de proporcionar maior gerenciamento de transações aplicação de nível

.

Assumindo (b) que você quer dizer o conceito arquitetônico geral da fachada da sessão -, então

A dissociação serviços e consumidores e fornecer uma interface amigável por cima disso é uma boa idéia. ciência da computação tem resolvido muitos problemas por 'adicionando uma camada adicional de engano'.

Rod Johnson escreve "SLSBs com interfaces remotas fornecer uma solução muito boa para aplicações distribuídas construídas sobre RMI. No entanto, este é um requisito minoria. A experiência tem mostrado que não quer usar arquitetura distribuída a menos que forçado pelas exigências. Nós ainda pode atender clientes remotos, se necessário através da implementação de uma fachada de comunicação remota em cima de um bom co-localizado modelo de objeto ". (Johnson, R "Desenvolvimento J2EE sem EJB" P119).

Assumindo (c) que considere a especificação EJB (e em particular o componente sessão de fachada) ser uma chaga sobre a paisagem de um bom design, em seguida:

Rod Johnson escreve "Em geral, não há muitas razões que você usaria um SLSB local em tudo em uma aplicação Spring, como Spring fornece gerenciamento de transações declarativa mais capaz do que EJB, e CMT normalmente é a principal motivação para a utilização SLSBs locais. Assim, você pode não precisar th camada EJB em tudo. " http://forum.springframework.org/showthread.php ? t = 18155

Em um ambiente onde o desempenho ea escalabilidade do servidor web são as principais preocupações - e custo é um problema - então a fachada de sessão arquitetura parece menos atraentes - que pode ser mais simples de falar diretamente com o datbase (embora este é mais sobre hierarquização.)