Arquitetura com Factory de Facades. Correto?

Só o BusinessDaelegate não te ajuda?

Acho que nao Daniel porque como eu preciso de um nivel de abstracao maior para nao amarrar minha aplicacao, utilizando AbstractFactory na camada dos facades e criando uma interface para cada facade acho que ao criar uma nova implementação dos PesistentManagers como a utilizacap de DAOs facilitaria para essa camada as alteracoes sem afetar as camadas que utilizam os dados destes facades.

&t

chcl:

Acho que nao Daniel porque como eu preciso de um nivel de abstracao maior para nao amarrar minha aplicacao, utilizando AbstractFactory na camada dos facades e criando uma interface para cada facade acho que ao criar uma nova implementação dos PesistentManagers como a utilizacap de DAOs facilitaria para essa camada as alteracoes sem afetar as camadas que utilizam os dados destes facades.

Só uma observação : Façade é uma coisa, Repository ( daos e afins) é outra completamente diferente.

Esse approach não é para melhor abstração e sim decoupling" da sua arquitetura.

Com relação à tudo que o você falou sobre Façade, Business Delegate … a primeira pergunta é , você vai utilizar EJB ?

Senão, utilize simplesmente o Proxy Pattern para o que quer, amarrado com IoC - nada de factories.

Utilize um framework como Spring para tal.

Desse jeito você vai separar a implementação como deseja com uma abordagem mais moderna e eficiente na hora de realizar seus testes - TDD.

Olá

Infelizmente quase nunca conseguimos desacomplamento do ambiente escolhido.

A adoção de EJB3, implica em algumas decisões que podem não ser acertadas caso amanhã eles sejam retirados do projeto.

Sigo estudando web services e já vi casos em que as atitudes mudam se há EJB3 ou não.

Me parece um pouco utópico criar esta intermediação achando que amanhã alguém deixará de usar EJB3 em um projeto que já começou com eles.

[]s
Luca

Luca:

Olá

Infelizmente quase nunca conseguimos desacomplamento do ambiente escolhido.

A adoção de EJB3, implica em algumas decisões que podem não ser acertadas caso amanhã eles sejam retirados do projeto.

Sigo estudando web services e já vi casos em que as atitudes mudam se há EJB3 ou não.

Me parece um pouco utópico criar esta intermediação achando que amanhã alguém deixará de usar EJB3 em um projeto que já começou com eles.

[]s
Luca

Alguns pontos da arquitetura podem ser traduzidos por intermédio de ESBs , fazer um webservice conversar diretamente com um EJB por exemplo.

Aqui você consegueria um desacoplamento maior, utilizando tais integradores.

Luca:

Olá

Infelizmente quase nunca conseguimos desacomplamento do ambiente escolhido.

A adoção de EJB3, implica em algumas decisões que podem não ser acertadas caso amanhã eles sejam retirados do projeto.

Sigo estudando web services e já vi casos em que as atitudes mudam se há EJB3 ou não.

Me parece um pouco utópico criar esta intermediação achando que amanhã alguém deixará de usar EJB3 em um projeto que já começou com eles.

[]s
Luca

Luca vc acertou em cheio o que ando pensando com relaçao a adoção de EJBs em minha aplicação. A adoção de EJBs implica em algumas questoes relacionadas a arquitetura da aplicação que acabam nos deixando limitado em alguns aspectos devido a propria arquitetura e natureza dos EJBs.

Estarei utilizando EJBs em minha aplicação com intuito de fazer a aplicação inteira com eles mais gostaria de ter um nivel de desacoplamento maior para permitir uma mudança futura de EJBs para algum outro tipo de componente sem afetar os clientes. como vc mesmo disse

“Me parece um pouco utópico criar esta intermediação achando que amanhã alguém deixará de usar EJB3 em um projeto que já começou com eles.
”

Vou utilizar os EJBs assumindo que eles vao dar conta do recado e que eu nao venha precisar de mudar a persistencia pra outro modelo.
Mais quero deixar uma brecha pra permitir essa alteração no modelo caso necessario.

Agora so pra fechar vou utilizar EJBs/JPA e Facades de onde as transacoes seram iniciadas.
Para permitir um maior desacoplamento entre a camada cliente e a camada de negocios qual a melhor opção ? Ou a melhor opcao é utilizar o modelo de Facades gerenciando as entidades JPA diretamente ??

Não pense demais cara. Isso sai “caro”.
Senão, hoje em dia você veria por ai carros onde vc simplesmente pode trocar o motor para um movido a hidrogênio quando sair a tecnologia no mercado.
Convenhamos… como, ponderadamente, disse o Luca, é utópico.

No meu projeto estou utilizando a seguinte estrutura

“APIs”

Entidades e interfaces dos delegates

Pessoa, PessoaFisica, PessoaJuridica

IPessoaBusinessDelegate extends GenericBusinessDelegate

Estou separando os delegates por grandes pacotes

Implementação

a implementação do delegate fica responsavel por acessar a implementação do facade

public class PessoaFacadeImpl extends Ejb3StatelessFacade implements PessoaFacade

PessoaBusinessDelegate fica responsavel por repassar as solicitações para o PessoaFacadeImpl

Somente a camada que eu chamo de API é que fica visível na aplicação. E para instanciar os delegates utilizo o Spring

Obs: Na estrutura que estou utilizando não seria necessário utilizar os delegates a implementação da interface poderia ser o próprio EJB.

Espero ajudar de alguma forma.

[]

Fred

considerações:_

1 : Se você está fazendo um extends do GenericBusinessDelegate, e está utilizando Spring, conceito de interfaces, pq criou uma interface especializada ? Pq não amarrou a implementação no container somente ?

2: Tente não utilizar o nome de Patterns, faça uma abstração real do problema.

3 : Se sua aplicação for Stateful, e você faz uso de component approach na camada view, considere a utilização de um framework como Seam, vai facilitar muito a sua vida e não vai precisar se preocupar com delegates, e afins - patterns J2EE, pois a infra-estrutura vai prover isso para você.

1 - Não é necessário utilizar extends GenericBusinessDelegate só estou utilizando essa interface na herança mesmo, só estou utilizando pois todos os Delegates possuiem metodos padrão e não queria ter que ficar copiando para todas as interfaces. Sei que poderia ser removido.

2 - No meu projeto estou agrupando os Delegates por grandes pacotes, no momento só tenho Pessoa e Segurança. Os delegates são responsáveis por todas as entidades do pacote. Ex. PessoaBusinessDelegate controla as entidades AreaConhecimentoCnpq, Deficiencia, Endereco, Escolaridade, EstadoCivil, Ies, Municipio, NivelOrgao, Orgao, Pais, Pessoa, PessoaFisica, PessoaFisicaDeficiencia, PessoaJuridica, PessoaLigth, PessoaPapel, Raca, RgOrgaoEmissor, SituacaoOrgao, SituacaoPessoaPapel, TipoCodigoNacional, TipoIdentificador, TipoOrgao, TipoOrgaoEscolaridade, TipoPapel, TipoPessoaJuridica, Titulacao, TitulacaoPessoaFisica, Unifed

Nesse caso como poderia chamar minha classe ?

3 - Estou utilizando Stateless e estou programando minha própria estrutura utilizando o conceito de serviços e Spring para inicializa-los, o acesso é realizado através de um gerenciador do serviços ServiceManager

• PropertyService
• FileUtilityService
• SqlMapService
• SecurityService
• SearchService
• MenuService