Arquitetura - Modelo de Negocio JEE DAO/JPA/Transacao/EJB

2 respostas
chcl

Galera estou levantando a melhor arquitetura pra um sistema de Missao Critica da qual estou com algumas duvidas antes de fechar e arquitetura da camada de negocios pra passar pra prova de conceito da mesma.
Ja Dei uma olhada nos topicos do GUJ e vi algo parecido com o que preciso mais queria algo mais concreto e opnioes pois abstracoes por abstracoes isso confunde qq um.

Seguinte, estou montando a arquitetura do Modelo de negocios de minha aplicação e eis o que estou pensando.

SessionFacade --&gt BusinessObject --&gt DAOs

Onde eu teria uma fabrica de DAOs com um DAO Generico com as operacoes de CRUD por exemplo.

Uma fabrica de BusinessObjects que encapsula transacoes e utiliza os DAOs

E SessionFacades para acesso cliente ao modelo de negocios.

Detalhando::
A questao é, de inicio estaremos usando JPA pra entidades onde eu teria um DAO pra cada entidade herdando funcoes comuns de CRUD de um DAO generico, e esses DAOs sendo disponiblizados atraves de um Factory(acho que esse é um modelo comun a todos e ate um pouco tosco pra JPA nas operacoes de CRUD devido o EM fazer o papel dos metodos genericos de CRUD mais preciso abstrair isso pra funcionar com outros bancos sem JPA). Importante lembrar que vou possuir outros tipos de DAOs como implementação manual sem JPA e é isso que ta criando duvidas quando utilizar esses DAOs com transacoes.

A fabrica de BusinessObjects sera para abstrair do Facade o papel de utilizar os DAOs e controlar as TRANSACOES. Eis onde estao minhas duvidas.TRANSACOES

Quando criar meus DAOs os mesmos deveram utilizar um EntityManager/JPA para executar suas operacoes no banco, o uso dos DAOs sera feito pelas classes BusinessObject que terao o papel de Iniciar as transações em para que a mesma possa ser propagada para os DAOs. Um exemplo de como seria um Facade chamando um metodo de meu BusinessObject:

FACADE:



BusinessObject obj = new BusinessObject();

obj.operacao1(x,y,z);


BUSINESSOBJECT:

@TransactionAttribute(TransactionAttributeType.REQUIRED)



public void operacao1(x,y,z){

dao1.insert(xx);

dao2.delete(xx)

dao3.algumacoisa(xx);

}

Ate ai blz pra EJBs com JPA assumindo que o contexto de transacao ser propagado e ele iniciara uma transacao no inicio do metodo e comitara a mesma no fim dele.

Agora se eu utilizar um DAO que nao seja JPA eu teria de ter um outro mecanismo de controle de transações, criei essa camada de BusinessObject para nao ter que ter um Factory de Facades e sim so um Factory de BusinessObjects para facilitar a manutenção e entendimento.

Agora a duvida mor, eu devo criar uma classe pra fazer o controle de transações para que eu nao precise dessa camada BusinessObjects ??
Nao sei se devo abstrair isso o que voces acham ??

Nao testei ainda mais realmente eu tornando meu BusinessObject um SessionBean e os DAOs e todas as classes envolvidas eu consigo propagar a transação ??

Pra falar a verdade é tanta coisa que nao sei se entenderam meu problema mais mesmo assim por favor ajudem ai se puderem!!

Em suma meu problema é criar uma arquitetura flexivel com DAOs utilizando Transações para meu modelo de negocios que pode ser EJBs com JPA ou outro tipo de implementação de DAOs o modelo que coloquei acima sei que resolve meu problema mais queria opnioes quem sabe alguem nao ja passou por esse problema né!!

Valews!!

2 Respostas

A

Confuso :roll: , que tal colocar um diagrama de sequência!?

Kenobi

Tou vendo aqui você utilizar várias vezes o conceito de Factory em pleno século 21 , quando tempos a opção de IoC :-).

Antes de eu começar a dar pitaco na sua arquitetura e lhe falar sobre transações ( que aliás, pode ser resolvido de maneira ridícula com um framework como Spring - AOP simples), o que você vai utilizar na sua camada view ? Será algo como JSF ?!

Por que estou vendo que vai usar EJB, JPA , tem factories, que deverão ser substituídas por um modelo IoC.

Já pensou num framework como JBoss Seam ? Acho que ele vai cobrir todas as suas necessidades.

Criado 27 de junho de 2007
Ultima resposta 3 de jul. de 2007
Respostas 2
Participantes 3