| Autor |
Mensagem |
|
|
Discuti um pouco sobre algumas coisas nesse post:
http://www.guj.com.br/posts/list/47179.java
Proteu, estou me limitando ao Java mesmo, mas creio que para qualquer linguagem/arquitetura o modelo de objetos ainda é um pouco longe do negócio.
Por exemplo, o post que mencionei diz que os entities no EJB 3.0 já podem sair livremente para a camada de apresentação, porém, não é a mesma coisa do que se tivesse no servidor. (Alguma linguagem ou arquitetura resolve isso de uma maneira melhor?)
É confuso, ao mesmo tempo que as coisas evoluem e ficam mais simples parece que mais e mais "workarounds" vão surgindo...
Não sei se estou sendo claro... a meu ver a informática vai começar a ficar legal quando não precisarmos mais do departamento de informática...
|
 |
|
|
Luiz, o problema de um sistema Desktop seja em Swing ou qualquer coisa é saber isolar legal os componentes não só para reutilizá-los mas também para manter uma boa coesão.
Para deixar componentes isolados nós usamos muito listeners (AKA Observers). Se você lembra do curso, existem mensagens call e signal.
Me manda um mail que um dia podemos até marcar para você ver o meu projeto atual...
Falow...
|
|
|
|
Duende, acho que as coisas já estão bem claras na sua cabeça de como as coisas vão funcionar na implementação, certo? Quanto mais claras as coisas na sua cabeça, menor é a necessidade de modelagem. Esse é o cerne do meu artigo sobre UML. UML é ferramenta de análise.
O Caso de Uso é importante para mapear requisitos. O Diagrama de Sequências você pode mapear o fluxo de processo ou do que ocorre no caso de uso, mas só para dar uma visão geral... Não vejo muita utilidade em um Diag. de Seq. que seja muito detalhado ao ponto de ter esse fork. Lucas.
Acho que essa central é mais um conceito da infraestrutura de rede do que um conceito de negócios. Talvez seja até melhor demonstrar isso usando um diagrama de implantação (se for interessante para o seu projeto).
|
|
|
|
|
Duende... o que seria essa "Central"? É um sistema externo?
|
|
|
|
Luca wrote:
Depois que a gente se acostuma a trabalhar deste jeito, já tem tudo pronto para reusar em outros projetos.
[]s
Luca
Estou fazendo mais um Pet Project na ASPERCOM nos moldes do Hotmotors. É parte do meu próximo artigo. Estou fazendo em Swing e EJB 3, se você quiser podemos fazer também na sua abordagem para podermos ver as diferenças...
De qualquer forma, ainda acredito que seria melhor que no futuro pudéssemos manusear os entities na camada de apresentação sem limitações, navegando livremente nas associações, chamando operações de negócio e com uma performance excelente...
Outro ponto: acho um pouco "utopia" uma camada de apresentação totalmente desacoplada. Mudanças no domínio quase sempre forçam uma mudança na camada de apresentação, sempre tem um campo novo que entrou, ou uma associação que teve multiplicidade alterada. Por mais que a apresentação esteja desacoplada, ela vai ter alterações motivadas pelo domínio...
|
|
|
|
Luca wrote:
No modelo que uso entre o Swing e o resto, há troca de mensagens usando arquitetura de mensagens HTTP e deixando a camada de apresentação o mais desacoplada possível.
Fiz sempre assim mesmo que o sistema rode todo no mesmo micro. O negócio é fazer uma vez para perceber que é fácil.
Só não me convidem para elogiar projeto que acessa EJBs no Swing a menos que me provem tim tim por tim o porque desta escolha. Até hoje vi poucos que justificassem corrretamente esta opção.
Camada de Apresentação "o mais desacoplada possível" é um custo alto. É bonito, mas também precisa justificar esse custo. Concorda? Outra coisa, concorda que trafegar XML com cópia dos dados dos objetos não seria a mesma coisa que usar DTOs?
Meu projeto acessa EJB direto no Swing de maneira simples, mas é EJB 3, onde os entities são livres para ir para o cliente, mas tem as limitações que já postei aqui... Agora, a produtividade é muito alta. Fazemos telinhas em minutos...
|
|
|
|
Luca wrote:A partir desta lembrança repito: não é complexo. Mas é claro que não basta ser certificado Java para saber como.
Tem certas coisas que o que limita é a tecnologia atual. Quando o cliente é desconectado você precisa tomar alguns cuidados a mais. Seria ótimo se você conseguisse obter as instâncias de entities no cliente Swing e as usasse livremente sem se importar com a transação, mas infelizmente isso ainda não é a realidade.
Algumas vezes você precisa usar um Stateful para driblar um LazyLoad, ou fazer uma interface remota que limite o que o cliente pode fazer no Swing, ou forçar um FetchType.EAGER. Resumo: Essa abstração de um objeto remoto ainda é falha, principalmente no controle transacional de operações remotas.
|
|
|
|
Luca wrote:Olá
Rodrigo, eu me ative a sua frase: tudo em uma única JVM.
Quanto a dificuldade de controle transacional com Swing eu não vejo nenhuma porque desde 2000 todos os sistema Swing em que eu participei do desenvolvimento NENHUM acessava a base de dados pela camada de apresentação Swing.
[]s
Luca
Luca, meus sistemas Swing também não acessam a base pela View! O resumo da arquitetura que estou usando agora é:
Panel -> Facade -> Domain Model
Nesse modelo, a transação inicia e termina no Facade...
|
|
|
|
Luca, as coisas estão tão estranhas que você está postando que creio que não estamos falando a mesma coisa!!! 
Vamos por partes:
1. Sistema Web rodando servlets e JSPs (ou Frameworks Web a escolher) no Tomcat dentro do Jboss tudo numa mesma máquina virtual. Melhor escolha para um controle de abertura e fechamento de transação: OpenSessionInView. Se não concorda poste uma opção melhor...
2. Sistema Desktop rodando Swing + servidor de aplicações, nesse caso, uma máquina virtual no cliente Swing e outra no AppServer. Nesse cenário, não dá para usar OpenSessionInView, pois a UnitOfWork não consegue migrar do client para o server. Você sabe uma maneira transparente da transação ocorrer na camada de apresentação de um sistema remoto?
Luca wrote:Olá
Sua frase sobre uma única máquina virtual que me refiro é esta e este pattern se chama JavaClipperTabajareitor
Gregor Hohpe, primeira linha do seu livro wrote:Interesting applications rarely live in isolation
Repito, se você se satisfaz com um sistema isolado que exige levar seu computador junto consigo, então use Clipper, VB ou Delphi.
Mas para mim nem agenda pessoal eu admito sem acesso à Internet pois quero acessá-la de onde eu estiver no mundo.
Não tem muita relação o número de máquinas virtuais de uma aplicação e o fato dela viver ou não em isolamento. E muito menos com a escolha de Java, Clipper, VB ou Delphi...
Luca wrote: Separar a camada de apresentação do acesso ao banco de dados não é introduzir complexidade. É apenas fazer um sistema que sirva para alguma coisa.
Em algum momento a transação tem que ser aberta, fechada ou deu uma exceção que precisa de rollback. O ponto é aonde isso deve ser feito...
Luca wrote:Cliente desconectado apenas significa que você não tem os demais componentes do sistema instalados e replicados em sua máquina.
Cara, não significa só isso não... acredite em mim, estou desenvolvendo aplicações Swing a mais de 5 anos e a questão do controle transacional ainda é muito precário. É uma luta contra a complexidade e um exemplo é esse post que fiz:
http://www.guj.com.br/posts/list/47015.java
|
|
|
|
Fabio Kung wrote:Realmente, clientes desconexos são bem mais complexos. Não adianta pensar em lazy-loading, você precisa saber exatamente o que mandar para o cliente remoto, pois o uso da rede/banda tem que ser otimizado.
Difícil decidir por essa complexidade toda só porque "um dia seu sistema pode ser acessado por uma interface desktop desconexa".
Muitas vezes é bem ruim adicionar muita complexidade tentando prever o futuro!
ps.: boa leitura => https://gettingreal.37signals.com/
Fala Fabio, atualmente, não tenho me preocupado em "saber exatamente o que tem que mandar". No EJB 3 tenho mandando os próprios entities para a camada de apresentação remota sem usar DTO. Aí sim o LazyLoad passa a ser uma preocupação... Mas prefiro essa preocupação do que a preocupação de ficar montando e desmontando DTO.
Rede/Banda otimizado? Não creio que vai ser 10K numa requisição RMI que vai deixar as coisas pesadas...
Outra coisa, a discussão não é sobre prever o futuro, só coloquei a questão do projeto desconectado para comparar, pois nesses projetos não dá para usar OpenSessionInView de jeito nenhum. OK?
Realmente é besteira querer deixar a sua camada de aplicação pronta para todo e qualquer cliente que queira se comunicar com o Domain Model...
|
|
|
|
Luca wrote:
Rodrigo, gosto muito das suas mensagens mas desta eu discordo.
Quem quer fazer uma aplicação com acesso a banco de dados na camada de apresentação como se fazia no milênio passado, deve usar Clipper, VB ou Delphi. Não usem Java para isto.
[]s
Luca
Fala Luca, também gosto das tuas mensagens, mas acho que tu não entendeu o que o pattern OpenSessionInView prega. Não estou falando para colocar comandos SQL nos JSPs, estou falando para colocar a ABERTURA e FECHAMENTO da transação na VIEW de forma a encapsular tudo o que acontece na requisição web numa unit of work...
Agora, estou dizendo no escopo de uma aplicação Java Web usando Struts, JSP ou outro framework web qualquer... Nesse cenário, não consigo ver uma opção que seja melhor que o OpenSessionInView...
Estou trabalhando num projeto Desktop em Swing, e choro muito todas as tardes por não poder abrir a transação no cliente desconectado! Cliente descontectado é mais complexo, tem que pensar nas questões do LazyLoad e objetos desatachados...
Mesmo num ambiente WebServices, continuo achando melhor deixar o controle transacional fora dos objetos de negócio... negócio é negócio, infra-estrutura é infra-estrutura...
Controle de transação é mais uma pedrinha no sapato da evolução dos sistemas OO...
|
|
|
|
brunohansen wrote:Na camada de apresentação mas no controle(MVC) né? Pois eu acho que eu posso trocar minha visão(MVC) sem afetar o controle de transação que esta no controle(MVC)
Rodrigo só uma dúvida! Controlar transações não seria o trabalho de uma "Unidade de Trabralho (Fowler)"?
Por incrível que pareça, o Open Session in View é na View mesmo, no V. Pensando num ambiente WEB, a cada requisição a transação é aberta logo que a requisição inicia e é fechada quando a requisição é renderizada no cliente. Tudo que ocorre dentro desse período é uma unit of work.
Não é difícil fazer isso usando o RequestProcessor do Struts ou a sugestão de usar filtros que o Diogo sugeriu... é a maneira mais simples de fazer num ambiente web, agora se é um cliente desconectado (como aplicação Swing) aí é diferente...
|
|
|
|
Se o seu sistema roda todo em uma única máquina virtual, a melhor solução é colocar o controle transacional na camada de apresentação usando um "pattern" chamado "Open Session in View".
http://www.hibernate.org/43.html
Tem uma implementação exemplo disso usando Struts no nosso site da Hotmotors (veja a implementação de HibernateRequestProcessor.java):
http://www.aspercom.com.br/hotmotors
Objetos de negócio são cegos com relação à transação.
|
|
|
|
Prezados(as),
Tem como injetar as coisas num entity no EJB 3.0? Testei aqui e não funciona (pelo menos não no JBOSS). O código é mais ou menos esse:
Por um acaso o Spring faz isso?
Aguardo!
Rodrigo Yoshima
|
|
|
|
Tive pouca experiencia em integrar um banco legado ao Hibernate, mas quando as coisas ocorrem no sentido contrário, do modelo de objetos para o modelo relacional, creio que anotations seja a maneira mais produtiva.
|
|
|
|