Arquitetura de sistema Swing

Programação Arquitetura
#41

[quote]Se estamos falando de sistemas grandes e muito distribuídos, a complexidade afeta a produtividade, mas distribuir sua aplicação tem benefícios que nenhum 2-camadas tem.

‘Produtividade’ é um termo de marketing que as pessoas cismam em usar tecnicamente. Delphi ‘é mais produtivo’ que Java. VB também. Que tal?
…
É besteira querer os benefícios sem pagar o preço, e o preço de um bom design é gastar algum tempo…bem, fazendo o design!
…
Você precisa definir melhor suas interfaces, resposabilidades e camadas.
[/quote]

“Produtividade” não é só um termo de marketing. É a produtividade da empresa de software para a qual você trabalha (suponho) que vai determinar se ela terá lucros ou prejuízos.

Além disso, sem um determinado nível de “produtividade” você pode não conseguir acompanhar o ritmo de alterações necessárias no sistema.
Mesmo sistemas bem desenhados estão sujeitos as mais brutais alterações. De fato, alguns já são projetados prevendo isso.

É indiscutível que o design deva ser bem pensado, e que dele dependerá o sucesso da aplicação. Por isso a “produtividade” deve ser um requisito importante a se considerar ao se definir as linhas gerais da aplicação.

Os problemas de acesso concorrentes e transacionais são todos resolvidos pelo servidor de aplicação. É para isso que ele serve, dentre muitas outras coisas, é claro.

No exemplo dado, a grande quantidade de informações entradas pelo usuário será conferida na tela antes do click no botão “Salvar” por exemplo. Os processos de negócio desencadeados no servidor de aplicação a partir daí nem sempre são facilmente reversíveis. Isso justifica a implementação descrita, que permite que o usuário corrija entradas erradas, minizando erros e processos corretivos.

Imagine o quão penoso pode ser recalcular o valor médio de um produto que sofre 500 mil movimentações de estoque todos os dias só porque um usuário informou equivocadamente o valor de um item no exemplo da Nota Fiscal que comentei anteriormente. É preciso minimizar as chances de que esse tipo de problema ocorra, fazendo com que as informações vindas da interface contenham o mínimo possível de erros e a implementação de formulário sugerida acima atende bem a tal requisito.

Mesmo hoje, existem sistemas (e muitos) em que isso é na verdade um requisito para a interface. Muitos processos industriais informatizados hoje são baseados no conceito de uma “especificação técnica” do produto que é usada como base para a produção. Cada vez que a indústria recebe um pedido do produto em questão a estrutura é duplicada e nela são alterados todos os pontos da especificação necessários para customizar o produto as necessidades do cliente (geralmente isso é feito por um engenheiro de produção qualificado).
Então devido a grande entrada de dados o formulário precisa oferecer ao usuário o maior número de facilitadores possíveis, como por exemplo o auto-preenchimento de campos com informações padrão ou o cálculo automático de algum valor que o usuário poderia deixar como está ou alterar para outro.

Nesse exmplo, manter essas informações juntas em um formulário não é uma questão de design e sim um requisito do sistema. Seria desconfortável para o usuário se essas entradas fossem feitas em formulários separados ou até mesmo em algum tipo de assistente ou algo do gênero.

#42

Se for assim, use VB. Um programador VB faz um sistema gigantesco em duas horas… ah, é claro, ele não consegue dar manutenção nele.

O que determina lucro/prejuízo em uma emrpesa, seja ela qual for, é uma série de fatores, dentre os quais a qualidade de um produto oferecido e o preço. Alguns investem em rpeço, outros em qualidade.

Produtividade é uma métrica itneressante. Primeiro que ninguém define o que é ser produtivo ou não. produtividade é contar linha de código/dia? Telas produzidas /dia? (se for isso, ferrou porque trabalho com back end, devo contar mensagens de log/dia).

Novamente ‘produtividade’ é palavra curinga: serve para tudo! o que tem a ver o sistema ficar pronto rápido ou demorar (medidas completamente relativas, aliás) com ele ser adaptável ou não?

Prever possíveis alterações futuras é um dos maiores erros que um designer pode cometer no mundo de hoje. Aumenta a complexidade desnecessariamente de um sistema, e na maioria dos casos o sistema não segue a previsão.

Desculpe, mas isso aí foi nada com coisa nenhuma.

Produtividade e Design? linahs gerais? O que você quis dizer com isso?

Acho que houve uma confusão aqui, de qualquer modo se você está com problemas com este escopo dentro de um ambiente de servidor, sua aplicação provavelmente está mal projetada. Camadas. Elas servem apra isso.

Não estou entendendo seu ponto. O que MVC tem contra isso? A boa definição de interfaces de negócio elimina muitos dos problemas que você poderia ter com esses requisitos, se você usar Swing, JSP, Struts, WebWork, SOAP, RMI… não importa!

J2EE, MVC, etc. são utilizados em sistemas de todos os tamanhos, incluindo sistemas com espoco muito maior e mais crítico do que você citou.

[quote=gcobr]Mesmo hoje, existem sistemas (e muitos) em que isso é na verdade um requisito para a interface. Muitos processos industriais informatizados hoje são baseados no conceito de uma “especificação técnica” do produto que é usada como base para a produção. Cada vez que a indústria recebe um pedido do produto em questão a estrutura é duplicada e nela são alterados todos os pontos da especificação necessários para customizar o produto as necessidades do cliente (geralmente isso é feito por um engenheiro de produção qualificado).
Então devido a grande entrada de dados o formulário precisa oferecer ao usuário o maior número de facilitadores possíveis, como por exemplo o auto-preenchimento de campos com informações padrão ou o cálculo automático de algum valor que o usuário poderia deixar como está ou alterar para outro.
[/quote]

Mesmo hoje existem sistemas (e muitos) em que COBOL é verdade.

[quote=gcobr]
Nesse exmplo, manter essas informações juntas em um formulário não é uma questão de design e sim um requisito do sistema. Seria desconfortável para o usuário se essas entradas fossem feitas em formulários separados ou até mesmo em algum tipo de assistente ou algo do gênero.[/quote]

Mas não há qualquer motivo para seu formulário processar regra de negócio.

Se você realmente precisa fazer uma transação batch (e se manter na década de 90, evitando tudo que um sistema distribuído tem de bom) você vait er este problema, mas se resolver entrar no século XXI vai poder utilizar Proxies leves para representar suas dez mil listas, e fazer seu cliente manipular apenas aquilo que realmente precisa, trazendo e enviando informações do/ao servidor apenas quando necessário.

Eu até agora não entendi Você disse que MVC não é produtivo, que não se aplica bem em arquiteturas com três camadas.

Arquiteturas de três camadas não necessariamente envolvem sistemas com requistios enormes, mas ainda que envolvam um cliente usando modelo MVC pode ser tão útil (ou inútil) quanto qualquer outro.

#43

Sem dúvida, qualidade e preço são fundamentais. O design deve sempre buscar um meio termo entre produtividade, qualidade e preço. Já que este último, o preço, vai ser diretamente proporcional ao tempo gasto no desenvolvimento.

Eu defino produtividade como: Entregar para a empresa cliente um produto que atenda suas necessidades em um prazo que seja curto o suficiente para que esta empresa possa gerar o maior lucro possível em decorrência de sua implantação, justificando o investimento realizado.

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

Rescrevendo: O design deve, além de atender todos os requisitos de negócio da aplicação, buscar a melhor produtividade possível para sua implementação.

Em momento algum eu disse que estou com problemas. Muito pelo contrário, a arquitetura pela qual optamos atende muito bem a todos os requisitos (inclusive ao da produtividade). E está sim dividida em camadas. 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.

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.

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?

Você tem toda razão. O formulário realmente não processa nenhuma regra de negócio. Todo o processamento feito tem como objetivo impedir erros na entrada de informações, ainda que a implementação seja mais complexa.

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.

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.

Cabe a cada desenvolvedor julgar o que é melhor para seu caso.

#44

Olá

Complementando minha resposta anterior com um exemplo de aplicação web de várias camadas usando V-C-M com interface de usuário swing.

Mais uma vez vou citar o Banco Postal.

:arrow: 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.
:arrow: Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
:arrow: 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.

[]s
Luca

#45

Gostaria ainda de acrescentar que no último JustJava, Michael Santos fez uma belíssima apresentação intitulada: Simplicidade, Produtividade, Testabilidade e Escalabilidade com J2EE, AOP e Rich Clients.

Nela foi feito um “estudo de caso” de um cliente da Summa para o qual a produtividade era um dos principais requisitos do sistema, já que o desenvolvimento seria seguido pela equipe do próprio cliente.

A aplicação demonstrada também não usa MVC entre a visualização (nesse caso em Thinlet) e o modelo (no servidor de aplicação), e nem por isso o seu design é ruim.

Os slides devem estar disponíveis para download.

#46

[quote=Luca]Mais uma vez vou citar o Banco Postal.

:arrow: 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.
:arrow: Controller - servlet que intermedeia as transações traduzindo para o formato ou protocolo adequado à camada adjacente.
:arrow: 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.
[/quote]

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.

#47

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.

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.

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

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?

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

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.

#48

Olá

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.

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

#49

Ô 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í?! :roll:

A Paz!!

#50

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

#51

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.

#52