Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
O Portal javafree.org inicia mais uma promoção para os usuários do fórum. Quem publicar mais posts válidos (perguntas ou respostas) entre 16/4 a 13/7 levará para casa um iPad 2 de 16GB!
Conforme indicaram alguns colegas de fórum, estou estudando Business Delegate e Service Locator para utilizar numa aplicação JSF (a ser desenvolvida) para resolver o problema de acoplamento da camada client com a camada de negócio. O problema é q todos os artigos e exemplos q encontrei são para EJB, e não estou conseguindo abstrair esses padrões para uma app em JSF.
Gostaria de saber se alguém já utilizou esses padrões em projetos, como foi implementado e se realmente valeu a pena. Ou mesmo, pedir que indicassem um bom material sobre a arquitetura de uma aplicação em JSF.
Os padrões Business Delegate e Service Locator, como apresentados no livro Core J2EE Patterns, têm como funções: - simplificar o uso de EJBs (BD) - simplificar o uso da API JNDI (SL)
Basicamente, eles existem unica e exclusivamente por causa dos EJBs (2.1)
Para ser justo, um Service Locator pode ser usado em outros contextos, ele é um padrão mais genérico de lookup de recursos/fábrica. Para esta função, uma alternativa é o uso de um container de injeção de dependências (leia-se 'Spring' ), que ainda oferece vantagens, como maior desacoplamento, flexibilidade e fornecimento de serviços sobre os componentes gerenciados. Leia mais aqui: Inversion Of Control - Containers de Inversão de Controle e o padrão Dependency Injection
Creio que o padrão que você procura é a Fachada (Façade) - e talvez o Transfer Object, caso a camada cliente acesse camada de negócio remotamente). A fachada cria uma fronteira bem definida para a camada de negócio, o que ajudaria no desacoplamento das camadas.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
O "protótipo" inicial da aplicação eu projetei com Fachadas. Essa foi a maneira mais simples de implementação de que falei, com os Backing Bean acessando as fachadas que por sua vez acessam a lógica do negócio.
Mas me agradou a idéia de ter um delegador de responsabilidades que conhecesse quais os responsáveis por determinada funcionalidade...
Mas me agradou a idéia de ter um delegador de responsabilidades que conhecesse quais os responsáveis por determinada funcionalidade...
Mas a fachada não poderia fazer esse papel? Aliás, a função da fachada é exatamente agregar diversas funções correlatas sob um ponto único de acesso.
GoF:
Facade - Intent: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Ahn, peraí.... eu acho que eles mudaram a descrição do padrão Business Delegate, da primeira para a segunda edição do livro. Pelo que eu me lembro, a única justificativa do padrão na primeira edição era realmente encapsular EJBs.
Mas na verdade ele seria simplesmente um objeto de domínio que se utiliza de outros para executar a sua lógica, coisa absolutamente natural em uma modelagem orientada a objetos. Não entendo o porque chamá-lo de delegate.
Aliás, a descrição do padrão está inconsistente com o diagrama geral dos padrões:
Em um, a fachada/serviço que chama o business delegate, e no outro, a view chama o delegate e este chama a fachada/serviço.
Afe, deixe esse Core J2EE Patterns pra lá e leia o Patterns of Enterprise Application Architecture, do Martin Fowler (no site tem as descrições resumidas). Ele é muito mais completo e consistente, e os padrões são bem mais voltados para problemas reais.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Acho que o diagrama de sequência que colocaste é do pattern "Business Object". No diagrama geral o padrão "Business Delegate" acessa a "Facade" e esta o "Business Object"...
Vou tentar utilizar o IoC do JSF, pq Spring já foi descartado para o projeto. Mas ainda não sei o que "injetar" no meu Backing Bean, o business delegate que acesse a fachada, ou diretamente a fachada (nem sei se isso é necessário).
Argh!!! Foi mal, não olhei direito e falei besteira. (bem que eu achei estranho... -sigh--)
Aqui está o diagrama correto:
Bem, mas olhando a descrição correta, dá pra ver que o padrão Business Delegate serve somente para esconder um EJB, ou alguma outra tecnologia de acesso remoto.
Se você usa Spring, ele faz isso pra você (faz o lookup e trata as exceções de remoting). E se você não utiliza camadas distribuídas, pra que o delegate?
Quanto ao JSF, o próprio pacote do Spring já prevê alguma integração, e no manual eles também apontam uma outra solução, o módulo JSF-Spring, um módulo externo (de terceiros, creio) que provê uma integração mais robusta.
Eu nunca testei a combinação JSF+Spring, então não sei o nível de integração que os pacotes dão, mas acho que vale a pena dar uma olhada.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Bem, que seja. As camadas vão estar distribuídas (em rede)?
Se sim, você pode usar delegates para encapsular o código que trata da comunicação remota. Se não, não vejo motivos para você criar essa camada extra.
Quanto ao Service Locator, ele é uma especialização de fábrica. Então, já que as dependências não vão ser injetadas via 'IoC', a alternativa mais óbvia é o uso de fábricas. Se no futuro elas vão se tornar Service Locators (lookup de serviços remotos), bastará refatorar a implementação interna da fábrica, já que a criação dos objetos está encapsulada.
_________________ In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Ok, as camadas não vão estar distribuídas... Deixa ver se eu entendi... então meus backing beans acessam fábricas de serviço ? algo, do tipo:
Então, a utilização de uma fachada poderia servir de ponto único de acesso para essas fábricas? ou ainda, utilizar uma fábrica geral com todos os serviços sendo seus produtos ?
carlosfpaixao Offline
Posts: 15
Olá a todos,
Conforme indicaram alguns colegas de fórum, estou estudando Business Delegate e Service Locator para utilizar numa aplicação JSF (a ser desenvolvida) para resolver o problema de acoplamento da camada client com a camada de negócio. O problema é q todos os artigos e exemplos q encontrei são para EJB, e não estou conseguindo abstrair esses padrões para uma app em JSF.
Gostaria de saber se alguém já utilizou esses padrões em projetos, como foi implementado e se realmente valeu a pena. Ou mesmo, pedir que indicassem um bom material sobre a arquitetura de uma aplicação em JSF.
ronaldtm Offline
Posts: 2299
Os padrões Business Delegate e Service Locator, como apresentados no livro Core J2EE Patterns, têm como funções:
- simplificar o uso de EJBs (BD)
- simplificar o uso da API JNDI (SL)
Basicamente, eles existem unica e exclusivamente por causa dos EJBs (2.1)
Para ser justo, um Service Locator pode ser usado em outros contextos, ele é um padrão mais genérico de lookup de recursos/fábrica. Para esta função, uma alternativa é o uso de um container de injeção de dependências (leia-se 'Spring'
Creio que o padrão que você procura é a Fachada (Façade) - e talvez o Transfer Object, caso a camada cliente acesse camada de negócio remotamente). A fachada cria uma fronteira bem definida para a camada de negócio, o que ajudaria no desacoplamento das camadas.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
carlosfpaixao Offline
Posts: 15
O "protótipo" inicial da aplicação eu projetei com Fachadas. Essa foi a maneira mais simples de implementação de que falei, com os Backing Bean acessando as fachadas que por sua vez acessam a lógica do negócio.
Mas me agradou a idéia de ter um delegador de responsabilidades que conhecesse quais os responsáveis por determinada funcionalidade...
ronaldtm Offline
Posts: 2299
Mas a fachada não poderia fazer esse papel? Aliás, a função da fachada é exatamente agregar diversas funções correlatas sob um ponto único de acesso.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
ronaldtm Offline
Posts: 2299
Ahn, peraí.... eu acho que eles mudaram a descrição do padrão Business Delegate, da primeira para a segunda edição do livro. Pelo que eu me lembro, a única justificativa do padrão na primeira edição era realmente encapsular EJBs.
Descrição nova:
http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm
Mas na verdade ele seria simplesmente um objeto de domínio que se utiliza de outros para executar a sua lógica, coisa absolutamente natural em uma modelagem orientada a objetos. Não entendo o porque chamá-lo de delegate.
Aliás, a descrição do padrão está inconsistente com o diagrama geral dos padrões:
Em um, a fachada/serviço que chama o business delegate, e no outro, a view chama o delegate e este chama a fachada/serviço.
Afe, deixe esse Core J2EE Patterns pra lá e leia o Patterns of Enterprise Application Architecture, do Martin Fowler (no site tem as descrições resumidas). Ele é muito mais completo e consistente, e os padrões são bem mais voltados para problemas reais.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
carlosfpaixao Offline
Posts: 15
Acho que o diagrama de sequência que colocaste é do pattern "Business Object". No diagrama geral o padrão "Business Delegate" acessa a "Facade" e esta o "Business Object"...
Vou tentar utilizar o IoC do JSF, pq Spring já foi descartado para o projeto.
ronaldtm Offline
Posts: 2299
Argh!!! Foi mal, não olhei direito e falei besteira. (bem que eu achei estranho... -sigh--)
Aqui está o diagrama correto:
Bem, mas olhando a descrição correta, dá pra ver que o padrão Business Delegate serve somente para esconder um EJB, ou alguma outra tecnologia de acesso remoto.
Se você usa Spring, ele faz isso pra você (faz o lookup e trata as exceções de remoting). E se você não utiliza camadas distribuídas, pra que o delegate?
Quanto ao JSF, o próprio pacote do Spring já prevê alguma integração, e no manual eles também apontam uma outra solução, o módulo JSF-Spring, um módulo externo (de terceiros, creio) que provê uma integração mais robusta.
Eu nunca testei a combinação JSF+Spring, então não sei o nível de integração que os pacotes dão, mas acho que vale a pena dar uma olhada.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
carlosfpaixao Offline
Posts: 15
Infelizmente não vou poder utilizar o IoC do Spring nesse projeto....
ronaldtm Offline
Posts: 2299
Bem, que seja. As camadas vão estar distribuídas (em rede)?
Se sim, você pode usar delegates para encapsular o código que trata da comunicação remota. Se não, não vejo motivos para você criar essa camada extra.
Quanto ao Service Locator, ele é uma especialização de fábrica. Então, já que as dependências não vão ser injetadas via 'IoC', a alternativa mais óbvia é o uso de fábricas. Se no futuro elas vão se tornar Service Locators (lookup de serviços remotos), bastará refatorar a implementação interna da fábrica, já que a criação dos objetos está encapsulada.
_________________
In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
carlosfpaixao Offline
Posts: 15
Ok, as camadas não vão estar distribuídas... Deixa ver se eu entendi... então meus backing beans acessam fábricas de serviço ? algo, do tipo:
Então, a utilização de uma fachada poderia servir de ponto único de acesso para essas fábricas? ou ainda, utilizar uma fábrica geral com todos os serviços sendo seus produtos ?
Relacionados
Padrões estrturais e padrões J2EE http://javafree.uol.com.br/topic-11176-Padroes-estrturais-e-padroes-J2EE.html JSF + EJB + Hibernate. Como usar os beans da melhor maneira? http://javafree.uol.com.br/topic-859639-JSF-+-EJB-+-Hibernate-Como-usar-os-beans-da-melhor-maneira.html EJB e JSP http://javafree.uol.com.br/topic-9840-EJB-e-JSP.html Dúvida com EJB + Padrões de Projeto http://javafree.uol.com.br/topic-880786-Duvida-com-EJB-+-Padroes-de-Projeto.html Acesso a um StatusBar http://javafree.uol.com.br/topic-851544-Acesso-a-um-StatusBar.html SESSION BEAN (STATEFUL) - VARIAS .JSP http://javafree.uol.com.br/topic-9989-SESSION-BEAN-STATEFUL-VARIAS-JSP.html Tutorial XDoclet + EJB + JBOSS http://javafree.uol.com.br/topic-3449-Tutorial-XDoclet-+-EJB-+-JBOSS.html