Duvida venda com EJB3
Olá pessoal
Tenho um trabalho de faculdade na qual tenho que desenvolver um tela de venda onde tenho seguinte caso de uso: O usuário deverá informar dados na capa da venda tais como cliente e condição de pagamento. Após informar a capa o usuário poderá informar itens para a venda, no caso uma lista de itens, cada item terá uma chave numérica, uma chave estrangeira transação, produto, quantidade e valor.
Após informar a capa e os itens o usuário terá três opções: Salvar → Será gravado a capa e os itens, sendo possível o usuário editar essa venda posteriormente, incluindo e excluindo itens. Fechar compra → Será gravado a capa e os itens e gerado contas a receber com base na condição de pagamento, não será permitido alterar essa venda posteriormente. Cancelar → Não grava nada e retorna a listagem.
Como devo proceder ao gravar a capa e os itens? 1 - Posso ao ir incluir um item já gravar a capa no banco, e a cada item que incluir persisti-lo no banco. Vantagem: se der problema ao incluir um item, os outros poderão ser persistidos. Desvantagem: se o usuário clicar em cancelar, não deveria gravar nada, mas a capa e os itens já foram gravador no banco O que fazer?
2 – Ao usuário clicar em salvar, gravar a capa e percorrer os itens gravando um a um, mas em caso de edição de uma venda eu teria de buscar todos os itens jogar em uma lista para que o usuário desse manutenção, depois excluir os itens do bancos e gravar novamente a lista editada. Vantagem: O cancelar funciona pq só será gravado no banco se o usuário salvar Desvantagem: Ao editar, o sistema terá de apagar os registros no banco e incluir novamente, pq não saberei se o usuário apagou ou incluiu outro item.
3 – Fazer como item 1, mas commitar a transação somento quando o usuário clicar em salvar, caso clique em cancelar em dou rollback. Vantagem: Parece que funcionaria em todos os casos Desvantagem: Ao ler sobre transação com EJB, vi que é altamente não aconselhável tratar transação manualmente, deixando isso com o container. Estou usando EJB3, e tenho um único SessionBean para venda que está anotado com Stateful Utilizo duas entidades Venda(Capa) e ItemVenda.
Se alguem poder me dizer qual seria a melhor solução ou dizer outra que resolva, agradeço!
No aguardo!
Tenho um trabalho de faculdade na qual tenho que desenvolver um tela de venda onde tenho seguinte caso de uso: O usuário deverá informar dados na capa da venda tais como cliente e condição de pagamento. Após informar a capa o usuário poderá informar itens para a venda, no caso uma lista de itens, cada item terá uma chave numérica, uma chave estrangeira transação, produto, quantidade e valor.
Após informar a capa e os itens o usuário terá três opções: Salvar → Será gravado a capa e os itens, sendo possível o usuário editar essa venda posteriormente, incluindo e excluindo itens. Fechar compra → Será gravado a capa e os itens e gerado contas a receber com base na condição de pagamento, não será permitido alterar essa venda posteriormente. Cancelar → Não grava nada e retorna a listagem.
Como devo proceder ao gravar a capa e os itens? 1 - Posso ao ir incluir um item já gravar a capa no banco, e a cada item que incluir persisti-lo no banco. Vantagem: se der problema ao incluir um item, os outros poderão ser persistidos. Desvantagem: se o usuário clicar em cancelar, não deveria gravar nada, mas a capa e os itens já foram gravador no banco O que fazer?
2 – Ao usuário clicar em salvar, gravar a capa e percorrer os itens gravando um a um, mas em caso de edição de uma venda eu teria de buscar todos os itens jogar em uma lista para que o usuário desse manutenção, depois excluir os itens do bancos e gravar novamente a lista editada. Vantagem: O cancelar funciona pq só será gravado no banco se o usuário salvar Desvantagem: Ao editar, o sistema terá de apagar os registros no banco e incluir novamente, pq não saberei se o usuário apagou ou incluiu outro item.
3 – Fazer como item 1, mas commitar a transação somento quando o usuário clicar em salvar, caso clique em cancelar em dou rollback. Vantagem: Parece que funcionaria em todos os casos Desvantagem: Ao ler sobre transação com EJB, vi que é altamente não aconselhável tratar transação manualmente, deixando isso com o container. Estou usando EJB3, e tenho um único SessionBean para venda que está anotado com Stateful Utilizo duas entidades Venda(Capa) e ItemVenda.
Se alguem poder me dizer qual seria a melhor solução ou dizer outra que resolva, agradeço!
No aguardo!
Marcus Antunes
Curtidas 0
Respostas
Dyego Carmo
04/05/2010
No caso dos itens , voce deve anotar a lista como CASCADE=ALL na entidade pai
deixe que o hibernate persiste para voce.
deixe que o hibernate persiste para voce.
GOSTEI 0
Marcus Antunes
04/05/2010
Dyego, eu até tentei fazer isso, mas dava uma exception dizendo que eu estava persistindo outra entidade (a ItemVenda) e nao aq eu passava no persist, no caso a Venda.
GOSTEI 0
Dyego Carmo
04/05/2010
Cole aqui o exception completo para que eu possa analisar.
GOSTEI 0
Marcus Antunes
04/05/2010
Dyego, eu concegui fazer o cascade aq...
Mas resta uma duvida, tem como fazer o EJB3 commitar minhas alterações PERSIST, REMOVE a partir de um determinado ponto?
exemplo:
Na seguinte tela o usuario poderá informar dados na capa, informar e remover itens e só no salvar tudo será gravado no banco? pensei em usar transacao mas nao sei é o caminho, o cascade ajudou pq preciso apenas persistir a capa q o itens vao junto, mas se eu editar esse pedido de venda e remover um item o cascade não adiantaria.
Mas resta uma duvida, tem como fazer o EJB3 commitar minhas alterações PERSIST, REMOVE a partir de um determinado ponto?
exemplo:
Na seguinte tela o usuario poderá informar dados na capa, informar e remover itens e só no salvar tudo será gravado no banco? pensei em usar transacao mas nao sei é o caminho, o cascade ajudou pq preciso apenas persistir a capa q o itens vao junto, mas se eu editar esse pedido de venda e remover um item o cascade não adiantaria.
GOSTEI 0
Andrei Hirata
04/05/2010
Olá..Voce poderia mandar uma parte do codigo fonte para ver o funcionamento? Estou trabalhando com ejb3.0 e talvez possa te ajudar.
No meu caso eu simplesmente faço assim
Todos os itens são alimentados em uma lista, e quando o usuário clica em finalizar venda, as vendas são gravadas no banco.
Para trazer os valores, simplesmente basta preencher a lista, acho que esta parte é bem facil ...
NO SEU CASO vc ja adiciona os produtos encontrados diretamente no banco, foi oq deu para entender. Acho que não é a melhor maneira de se fazer isto.
TRANSAçoes? ISTO DEPENDE DE COMO VC TA TRABALHANDO. é vc que gerencia as transaçoes? ou é o servidor de container? não sei como está sua configuração de persistencia.
Mas vamos lá, faça oq eu lhe disse da lista, que é a melhor forma de se trabalhar com cabeçalho e itens cabeçalho.
SE VC ANEXAR O CODIGO, EU POSSO ATÉ ANALISAR SEU CODIGO E LHE DAR DICAS.ABRAÇOS
SÓ A PARTE DA VENDA...NAO PRECISA SER TUDO
No meu caso eu simplesmente faço assim
Todos os itens são alimentados em uma lista, e quando o usuário clica em finalizar venda, as vendas são gravadas no banco.
Para trazer os valores, simplesmente basta preencher a lista, acho que esta parte é bem facil ...
NO SEU CASO vc ja adiciona os produtos encontrados diretamente no banco, foi oq deu para entender. Acho que não é a melhor maneira de se fazer isto.
TRANSAçoes? ISTO DEPENDE DE COMO VC TA TRABALHANDO. é vc que gerencia as transaçoes? ou é o servidor de container? não sei como está sua configuração de persistencia.
Mas vamos lá, faça oq eu lhe disse da lista, que é a melhor forma de se trabalhar com cabeçalho e itens cabeçalho.
SE VC ANEXAR O CODIGO, EU POSSO ATÉ ANALISAR SEU CODIGO E LHE DAR DICAS.ABRAÇOS
SÓ A PARTE DA VENDA...NAO PRECISA SER TUDO
GOSTEI 0
Marcus Antunes
04/05/2010
Olá, acabei de fazer tudo funcionar aq, mas ainda estou refinando o código.
Acabei por controlar a transacao nao mão usando a UserTransaction, tenho que ver ainda como vai ficar o funcionamento ainda.
Andrei obrigado pela dica, já tentei isso, e concordo que é a melhor opção para fazer um venda, nesse caso eu usei Cascade, conforme o Dyego havia dito. Mas nesse caso trata-se de um pedido de venda, ou seja o usuario nao é obrigado a fatura a venda na hora, podendo apenas salva-lo e posterirmente edita-lo, alterando seus itens. Nesse momento da edição os itens já estão no banco, eu só carrego ele na tela para o usuário.
No maximo até domingo(09/05) eu posto o código funcionando, para que, caso no futuro alguem precise.
Abaixo tem a parte do codigo que eu alterei.
Acabei por controlar a transacao nao mão usando a UserTransaction, tenho que ver ainda como vai ficar o funcionamento ainda.
Andrei obrigado pela dica, já tentei isso, e concordo que é a melhor opção para fazer um venda, nesse caso eu usei Cascade, conforme o Dyego havia dito. Mas nesse caso trata-se de um pedido de venda, ou seja o usuario nao é obrigado a fatura a venda na hora, podendo apenas salva-lo e posterirmente edita-lo, alterando seus itens. Nesse momento da edição os itens já estão no banco, eu só carrego ele na tela para o usuário.
No maximo até domingo(09/05) eu posto o código funcionando, para que, caso no futuro alguem precise.
Abaixo tem a parte do codigo que eu alterei.
@Stateful
@TransactionManagement(TransactionManagementType.BEAN)
public class TransacaoBean implements TransacaoBeanLocal, TransacaoBeanRemote {
@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EntityManager em;
@Resource
private UserTransaction tx;
@Override
public void beginTransaction() throws Exception {
tx.begin();
}
@Override
public void commitTransaction() throws Exception {
tx.commit();
}
@Override
public void rollbackTransaction() throws Exception {
tx.rollback();
}
@Override
public Transacao gravarTransacao(Transacao transacao) throws BusinessViolation, Exception {
validar(transacao);
em.persist(transacao);
return transacao;
}
GOSTEI 0
Andrei Hirata
04/05/2010
Apenas um pouco de experiencia...
Como voce está adiocionado valores, usando a persistencia, uma vez que a transação não seja completada, todas informações ficam armazenadas no cache do banco de dados. Dependendo do porte voce pode aumentar e diminuir estes caches a sua vontade.
Se vc usar seu programa para grande quantidade de trafego de dados, o banco pode congestionar, uma vez que os caches poderão ser consumidos exageramente.
Imagine 1000 transaçoes que ainda não foram fechadas , e que esperam ser finalizadas ou canceladas . OU SEJA COMMIT ou ROLLBACK
No caso aonde não existe este enorme tráfego, ainda eu não recomendo..Vou lhe dizer o porq..
1-Uma vez que os dados ficam em cache, existe a possibilidade de os dados sejam perdidos e até mesmo corrompido. ESTE CASO acontece geralmente em redes wireless ou internet lenta...
2-Várias transacoes abertas podem ser perdidas caso a internet caia e não poderão ser recuperadas,tendo que abrir uma nova transação.
3-Quanto mais transacoes abertas, mais recursos o servidor consome
BOM,acho que chega...agora o ponto forte de se usar uma lista COM seção STATEFULL
1-os dados ficam armazenados na memória do computador, e só serão perdidos se o pc desligar.Mesmo que a internet caia, não será nenhum problema, pois a transação só será aberta quando o usuario clicar em finalizar.
2-Se vc usar cookies, os valores que foram perdidos, se seu pc reiniciar, poderão ser recuperdas e depois vc continuará de onde parou
3-Será aberta apenas 1 transaçao por venda e este será usado de forma rápida,liberando recursos para as proximas movimentações.
Como vc pode ver....existe várias vantagens em se usar uma lista com seção e cookies...ao invez este ficar tacando os valores no cache do banco e depois persistir tudo
Como voce está adiocionado valores, usando a persistencia, uma vez que a transação não seja completada, todas informações ficam armazenadas no cache do banco de dados. Dependendo do porte voce pode aumentar e diminuir estes caches a sua vontade.
Se vc usar seu programa para grande quantidade de trafego de dados, o banco pode congestionar, uma vez que os caches poderão ser consumidos exageramente.
Imagine 1000 transaçoes que ainda não foram fechadas , e que esperam ser finalizadas ou canceladas . OU SEJA COMMIT ou ROLLBACK
No caso aonde não existe este enorme tráfego, ainda eu não recomendo..Vou lhe dizer o porq..
1-Uma vez que os dados ficam em cache, existe a possibilidade de os dados sejam perdidos e até mesmo corrompido. ESTE CASO acontece geralmente em redes wireless ou internet lenta...
2-Várias transacoes abertas podem ser perdidas caso a internet caia e não poderão ser recuperadas,tendo que abrir uma nova transação.
3-Quanto mais transacoes abertas, mais recursos o servidor consome
BOM,acho que chega...agora o ponto forte de se usar uma lista COM seção STATEFULL
1-os dados ficam armazenados na memória do computador, e só serão perdidos se o pc desligar.Mesmo que a internet caia, não será nenhum problema, pois a transação só será aberta quando o usuario clicar em finalizar.
2-Se vc usar cookies, os valores que foram perdidos, se seu pc reiniciar, poderão ser recuperdas e depois vc continuará de onde parou
3-Será aberta apenas 1 transaçao por venda e este será usado de forma rápida,liberando recursos para as proximas movimentações.
Como vc pode ver....existe várias vantagens em se usar uma lista com seção e cookies...ao invez este ficar tacando os valores no cache do banco e depois persistir tudo
GOSTEI 0
Marcus Antunes
04/05/2010
Andrei, tem razão!
Estou tentando evitar o uso de transações que não sejam controladas pelo container mas não vejo outra escolha para esse caso! Estou lendo Enterprise Javabeans 3.0 e lá diz q não é recomendavel controlar transações na mão.
Vou fazer uma analise melhor dessa situação. Sou novo com EJB 3 e estou aproveitando esses problemas para ganhar experiencia.
Muito obrigado pela ajuda!
Estou tentando evitar o uso de transações que não sejam controladas pelo container mas não vejo outra escolha para esse caso! Estou lendo Enterprise Javabeans 3.0 e lá diz q não é recomendavel controlar transações na mão.
Vou fazer uma analise melhor dessa situação. Sou novo com EJB 3 e estou aproveitando esses problemas para ganhar experiencia.
Muito obrigado pela ajuda!
GOSTEI 0
Dyego Carmo
04/05/2010
Que bom que conseguiu resolver :_)
GOSTEI 0