Arquitetura de sistema Swing...

Luca wrote:Mais uma vez vou citar o Banco Postal.

View - uma applet que apenas e tão somente captura dados, faz sua consistência e os envia para o servidor. É toda componentizada e usa diversos design patterns. Só aqui são mais de 1200 classes.
Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
Model - onde ficam as regras de negócio na verdade é composto de várias camadas sendo algumas em Brasília e outras em SP. Não foi feito em Java.

As transações trafegam usando protocolo web (http/https) entre as camadas só com seus dados, não são objetos serializados.

Avaliamos uma arquitetura assim também para nosso caso. Porém seria necessário muito código para passar as informações dos objetos para HTTP e também para apresentá-las na interface caso não fossem objetos.

Isso porque não poderiamos fazê-lo automaticamente, seria necessário implementar um algorítmo específico para cada formulário da interface.

A não ser que fossem enviados via HTTP objetos serializados em XML, mas aí seria quase o mesmo que serializar direto.

gcobr wrote:
Me refiro a produtividade na realização das adaptações. Essa é a relação.

Um 'design produtivo'? É difícil avaliar o quanto um design é produtivo em mudanças numa implementação quando você não sabe o que vai acontecer. A 'produtividade' cai por terra.

gcobr wrote:
Apenas não existe MVC entre a camada de visualização (Swing) e o modelo (no servidor de aplicação).

Por outro lado, temos MVC, na implementação da camada de visualização. Objetos que recebem (ou apresentam) dados do usuário são o modelo para formulários e demais controles visuais.

Isso é complicado. Você vai replicar o domínio na apresentação, muitas vezes desnecessariamente. Sem generalizações, não é possível sugerir uma bomba dessas para todos.

gcobr wrote:
O MVC não tem nada com isso. Meu comentário foi para demonstrar como a apresentação dos dados do exemplo em um único formulário é um requisito importante para o sistema, bem como a execução de processos de negócio não reversíveis somente após um "OK" do usuário.

Então porque você colocou isso numa discussão soobre MVC?

gcobr wrote:
Você sugere então que a interface deva ser projetada visando primordialmente padrões de projeto sem levar em consideração a usabilidade e agilidade de que o usuário precisa?
Ou que talvez seja mais prático implementá-la em COBOL?

Não, estou dizendo que produtividade é uma métrica relativa, marketeira e incomparável. E se o cliente quiser COBOL, quem sou eu para reclamar?

gcobr wrote:
Aí é que está. No meu exemplo, o cliente precisa manipular todas as minhas "dez mil listas". Sem exceções. Nenhuma informação desnecessária é enviada do servidor para o cliente.
E também utilizo proxies em outros casos onde apenas um parte do grafo de objetos interessa.

E qual a limitação de MVC quanto a isso?

gcobr wrote:
O que eu disse é que MVC entre um domínio de objetos no servidor de aplicação e uma interface Swing é algo complexo, e que a implementação disso pode ser pouco produtiva, pois pode envolver DTOs e argumentei a respeito.
Em contra partida, MVC num escopo menor como a interface pode ser muito útil.

O foco da discussão é o M. MVC divulga uma ótima prática que é separar lógica de apresentação do diálogo de usuário, mas isso não é feito só em MVC. Não é porque você não usa MVC que você não tem Model.

O sistema que você descreveu também acessa seu domínio, também vai precisar de transfer objects se necessário... não existe motivo para dizer que MVC é pouco produtivo porque você vait er que usar uma ou otura coisa que você vai acabar usando mesmo fora de um modelo MVC.

Não existe bala de prata, e MVC pode acrescentar complexidade desnecessária à mutias aplicações, mas quando sua interface cresce, é sempre interessante seu uso.

Olá

gcobr wrote:...seria necessário implementar um algorítmo específico para cada formulário da interface...

Não sei do seu caso, mas no Banco Postal há no máximo umas cento e poucas transações. Como foi tudo componentizado, o trabalho não foi tão grande assim. Tudo sempre era feito de modo genérico dentro da cadeia de responsabilidades. Em apenas 6 meses se partiu do zero e se colocou em produção.

gcobr wrote:...A não ser que fossem enviados via HTTP objetos serializados...

Trabalhei em uma outra aplicação muito mais simples (captura de cartão de crédito) em que as transações trafegavam como objetos serializados por http/https. Coloquei http em negrito porque isto para mim é o mais importante pois http passa em qualquer firewall. O fato dos objetos estarem serializados simplificou muito o desenvolvimento, principalmente do servidor que funcionava como Controller. Como tudo era genérico era assustador o tamanho minúsculo dele. Por reflection se obtia tudo. Mas no Banco Postal havia o requisito de 200 tps e aí se decidiu codificar mais para não sacrificar o throughput.

[]s
Luca

Ô galera, dei uma sumida pois estava praticamente off line...

Bom, já vi que existem várias opniões sobre o caso.Mas eu gostaria de saber uma outra coisa:Como vcs fazem o controle de transação?!

O problema é que minhas classes de regra de negócio podem fazer uso de outras classes de regra de negócio, daí não posso ficar colocando commit em todos os métodos dos DAO's.

E aí?!

A Paz!!

Paulo,

Não pense em transações como restritas ao banco de dados, pense nelas em sistema como um todo.

Dê uma lida em artigos de JTA.

[]s

Utilizando OO vc elimina a situação de vc poder vir a ter alguma ação específica.

Ex: Vc tem a classe a interface Generic com os métodos A, B e C e a classe UsuarioDAO que implementa Generic. Vc precisa do método XYZ, que será específico para UsuarioDAO? Então crie um classe UsuarioEspecifica (ou qualquer outro nome) que extende UsuarioDAO. A partir daí vc passa a chamar UsuarioEspecifica e não mais UsuarioDAO, eleminando o seu problema.

Acho que é isso.

Abraço.

Notícias, artigos e o maior fórum brasileiro sobre Java