Pessoal devido a necessidade de utilizar EJB3/JPA em minha aplicação e deixar de alguma forma flexibilidade para caso deixe de usar EJBs estou pensando na seguinte arquitetura e gostaria de opniao de voces a respeito.
Estou pensando em utilizar as Entidades mapeadas com JPA e uma fabrica de Facades logo em seguida com um FacadeAncestral com metodos comuns como CRUD e herdar isso nos demais Facades. Isso porque necessito de utilizar controle de transações entao como vou utilizar de inicio o controle do container esse foi o ponto de abstração que encontrei. Eu poderia ate criar uma camada antes do Facade pra isso mais acho que vai gerar um Overhead a mais atoa. E a flexibilidade vai se dar pelas interfaces e pelo factory de Facades onde caso nao de certo a utilização dos EJBs a fabrica pode me retornar uma outra estrutura de persistencia onde o controle de transação sera feito no Facade.
Deu pra entender ??
Sera que essa é a melhor solução ??
Utilizo o Facade mesmo ou crio uma outra camada intermediaria ??
Vou acessar esses Facades pelo com JSF com um BusinessDelegate na ponta que seria uma especie de Facade na Camada Web entao caso altere a implementação do Facade isso nao afeta meu cliente.
O que acham da Solução ?
Em suma preciso dessa flexibilidade porque isso é pra um sistema 24*7 Missao Critica que caso os EJBs nao correspodam ao esperado ja esteja preparado para algum outro mecanismo de persistencia sem comprometer a camada de apresentação nem a produtividade, tudo isso sem complicar demais é claro.
O uso de AbstractFactory com DAOs utilizando os Patterns J2EE seria o perfeito senao fosse o problema que surge com a necessidade do controle de transação que pretendo utilizar o do container inicialmente.
Por favor postem suas opniões para que eu possa evoluir isso e chegar num ponto que possa partir pra prova de conceito.
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[quote=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.[/quote]
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.
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
[/quote]
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 [quote]“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.
”[/quote]
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.
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