Arquitetura de sistema Swing...

paulohbmetal wrote:

Por isso mesmo que falo...Onde está a análise?!

Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer... seja lá que bizarrice inventarem...

paulohbmetal wrote:
Estava também olhando EJB e me parece uma boa, mas entro na velha história do "escrever mais"...Dá-lhes Deployment Descriptors...

Dá pra evitar muito do trabalho com xdoclet, mas, sinceramente, não vale a pena. Fique onde está...

[]s

This message was edited 1 time. Last update was at 17/11/2004 09:38:50

pcalcado wrote:
Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer... seja lá que bizarrice inventarem...

Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?!

pcalcado wrote:Dá pra evitar muito do trabalho com xdoclet, mas, sinceramente, não vale a pena. Fique onde está...

Pois é, e o EJB 3.0?!Vcs acham que resolve o problema?!

A promessa é essa né?!...

A Paz!!

O problema de análise seguindo os meios tradicionais é que você perde muito tempo desenvolvendo algo que não agrega nenhum valor ao seu projeto e que pode ser jogado no lixo a qualquer mudança de humor do seu cliente.

Então, cuidado antes de abrir sua ferramentinha CASE e sair desenhando alucinadamente o sistema inteiro, usando 8 diagramas da UML e o diabo.

Sobre EJB 3.0, o mecanismo de persistência ainda é mais promessa do que realidade. Ainda me pergunto se, quando a especificação for lançanda, eu vou adotá-la ou permanecer ao lado do Hibernate para persistência

Aliás, uma boa visão sobre este assunto é a do Tirsén: http://blogs.codehaus.org/people/tirsen/archives/000706_why_i_still_wont_do_ejb.html

paulohbmetal wrote:

pcalcado wrote:
Cuidado, paulo, a análise vai te dar algo para iniciar seu sistema, os requisitos mudam a todo instante a sua (nossa) obrigação é saber atender ao cliente como ele quer... seja lá que bizarrice inventarem...

Tudo bem, mas vc desenvolver uma aplicação em Swing e no dia de apresentar vc decobrir que era pra Web é demais né?!

Claro que é demais, foi apenar um exemplo bobo, para ver alguns problemas que podem aparecer. Como o Philip falou mesmo com MVC teu sistema pode ficar estremamante acoplado e isso não é bom. Por isso trabalhar com padrão de projetos é o ideal, IoC, Observer, e por ai vai é importante.

Sobre analise, eu prefiro a visão do XP, não pense que a analise te afasta de todos os males, pois o mais comum é definir coisa demais que na realizadade o cliente não precisa. É aquela famosa figura do balanco.

]['s

Daniel Quirino Oliveira wrote:Sobre EJB 3.0, o mecanismo de persistência ainda é mais promessa do que realidade. Ainda me pergunto se, quando a especificação for lançanda, eu vou adotá-la ou permanecer ao lado do Hibernate para persistência

E se tu usar Hibernate3 estara usando EJB 3.0, correto?

Segundo o Gavin na entrevista ao JF o Hib3 sera uma implementação da especificação do EJB 3.0 a qual ele é um dos menbros.

]['s

Alguns comentários:

Se você optar por uma arquitetura em 3 camadas (cliente swing, app server e DB) dificilmente conseguirá implementar um MVC que ligue a View (swing) ao Model (domínio de objetos no app server). Pelo menos não de uma forma muito produtiva.

Há cerca de um ano estou trabalhando em um sistema de grande porte que utiliza uma arquitetura assim. Levamos cerca de 6 meses só para defini-la: quais frameworks seriam usados, que EJB faria o que, como resolveriamos a persistência, etc.

O mais provável é que você implemente MVC na interface para apresentar dados dos seus objetos de domínio em formulários Swing.

Me parece também que existe uma série de questões complicadas que ainda não foram ponderadas para este caso:

* A serialização e transporte de objetos do app server para o cliente e vice versa pode se tornar um grande problema. Quanto maior o número de relações entre os objetos pior será. Para resolver isso, terá que implementar proxies e possivelmente trabalhar com uma estrutura paralela de DTOs (Data Transport Objects). Escrevendo cada vez mais e mais código.

* Certamente serão necessárias validações da entrada de dados no lado cliente. Os controles do swing (JTextFields, etc) provavelmente terão que ser estendidos para isso, ou você terá que criar Documents e outros modelos para eles.

* Frameworks para desenvolver UI Swing são escassos e menos populares do que os que você encontra para Web. Prepare-se para escrever muito código!

Desenvolver interface em Swing é geralmente muito menos produtivo do que desenvolver interface Web. Você morre nos detalhes!
Ao apresentar a aplicação para o cliente ele esperará encontrar na interface uma riqueza de detalhes e facilidades de uso e interação que qualquer programador Delphi ou VB consegue fazer com meia dúzia de clicks, mas que vão te custar a alma para desenvolver em Swing.

Dependendo dos requisitos pode ser muito mais fácil usar XUL, com Thinlet ou outro qualquer.

Gabriel.

gcobr wrote:
Se você optar por uma arquitetura em 3 camadas (cliente swing, app server e DB) dificilmente conseguirá implementar um MVC que ligue a View (swing) ao Model (domínio de objetos no app server). Pelo menos não de uma forma muito produtiva.

Não necessariamente. Uma estrutura bem distribuída oferece interface entre componentes de negócio e apresentação, a apresentação MVC utiliza esta interface como Model.

[]s

pcalcado wrote:
Não necessariamente. Uma estrutura bem distribuída oferece interface entre componentes de negócio e apresentação, a apresentação MVC utiliza esta interface como Model.

Você tem alguma idéia de como criar tal interface de maneira produtiva?
Imagine que você tem que desenvolver um formulário para entrada de todos os dados de uma Nota Fiscal recebida por uma indústria em um sitema ERP. Imagine que o objeto NotaFiscal tem uma coleção de itens e que para cada item desta coleção existem mais duas coleções e siga assim até totalizar uns 5 níveis de detalhamento. Imagine que esse detalhes devam ser informados no formulário e que ao final de tudo o usuário possa clicar em um botão "Salvar" que além de enviar o objeto para persistência no app server vai, através de Session Beans, gerar toda a movimentação de estoque necessária para o sistema e executar mais uns 10 processos em várias outras áreas do sistema (usando todos os detalhes informados) em decorrência da entrada dessa Nota Fiscal.

Um cenário assim não seria nenhum absurdo em um sistema de gestão integrado de uma empresa de grande porte.

Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.

gcobr wrote:
Você tem alguma idéia de como criar tal interface de maneira produtiva?

Sim, arquitetura de Objetos distribuidos em camadas.

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!

gcobr wrote:
Imagine que você tem que desenvolver um formulário para entrada de todos os dados de uma Nota Fiscal recebida por uma indústria em um sitema ERP. Imagine que o objeto NotaFiscal tem uma coleção de itens e que para cada item desta coleção existem mais duas coleções e siga assim até totalizar uns 5 níveis de detalhamento. Imagine que esse detalhes devam ser informados no formulário e que ao final de tudo o usuário possa clicar em um botão "Salvar" que além de enviar o objeto para persistência no app server vai, através de Session Beans, gerar toda a movimentação de estoque necessária para o sistema e executar mais uns 10 processos em várias outras áreas do sistema (usando todos os detalhes informados) em decorrência da entrada dessa Nota Fiscal.

Você precisa definir melhor suas interfaces, resposabilidades e camadas.

Dependendo do nível de distribuição e complexidade, você irá usar objetos DTO para passar dados agrupados, isso é uma limitação terrível de arquiteturas distribuídas, mas não é impossível de lidar.

Pelo seu escopo, eu acho que você está fazendo sua aplicação (de exemplo) cliente trabalhar demais, e fazer operações em lote, para depois enviar o resultado. O tempo do batch já passou, e você conseguirá problemas terríveis de acesso concorrente e transacionamento desta forma.

Se estamos falando de componentes distribuídos, aconselho uma leitura sobre o tema. Objetos internos à componentes não devem passear pelo sistema.

gcobr wrote:
Um cenário assim não seria nenhum absurdo em um sistema de gestão integrado de uma empresa de grande porte.

Em telecomunicações, geralemnte você possui mais de 3 tipos de interface para um sistema. A lógica de negócios é uma, o que varia é a interface.

Um modelo MVC utiliza as mesmas interfaces de negócio que um protocolo binário de tempo real. Para o modelo MVC, apenas estas interfaces são o modelo, para os outros clientes geralmente é um subsistema a ser acessado.

gcobr wrote:
Codificar isso em um formulário já é bastante trabalhoso e codificar algo mais entre as camadas me parece ainda mais.

Codificar isso num formulário é se manter na década de 90 para sempre. A arquitetura cliente/servidor é defasada, e mesmo essa arquitetura é má utilizada quando formulários executam regras de negócio, existem alternativas ainda dentro deste paradigma.

Olá

gabriel wrote:Se você optar por uma arquitetura em 3 camadas ... dificilmente conseguirá implementar um MVC que ligue a View (swing) ao Model (domínio de objetos no app server).

MVC do jeito que vc fala no Java só existe no Swing e mesmo assim parcialmente. O modelo dos frameworks web (mesmo JSF) V-C-M e V não deve dialogar diretamente com M.

gabriel wrote:O mais provável é que você implemente MVC na interface... Swing.

OK, vide obs. acima

gabriel wrote:* A serialização e transporte de objetos ...

Nem sempre é preciso serializar os objetos. Concordo que é bem prático em termos de programação mas se o objetivo for performance é melhor dedicar um pouco mais de tempo no desenvolvimento e facilitar o uso na produção.

gabriel wrote:* Certamente serão necessárias validações da entrada de dados no lado cliente...

Certo, tudo deve ser componentizado, padronizado, pasteurizado, flavorizado, customizado, colorizado e dará muito trabalho.

gabriel wrote:Ao apresentar a aplicação para o cliente ....

O cliente resolveu usar Linux e nós já estamos prontos para tal. Vide Droga Raia, Banco Postal, etc.

[]s
Luca

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.

"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.

Pelo seu escopo, eu acho que você está fazendo sua aplicação (de exemplo) cliente trabalhar demais, e fazer operações em lote, para depois enviar o resultado. O tempo do batch já passou, e você conseguirá problemas terríveis de acesso concorrente e transacionamento desta forma.

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.

Codificar isso num formulário é se manter na década de 90 para sempre. A arquitetura cliente/servidor é defasada, e mesmo essa arquitetura é má utilizada quando formulários executam regras de negócio, existem alternativas ainda dentro deste paradigma.

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.

gcobr wrote:
"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.

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).

gcobr wrote:
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.

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.

gcobr wrote:
É 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.

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

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

gcobr wrote:
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.

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.

gcobr wrote:
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.

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.

gcobr wrote: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.

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

gcobr wrote:
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.

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.

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.

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.

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).

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.

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?

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

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

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

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.

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.

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.

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!

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.

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

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?

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

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.

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.

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.

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.

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.

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.

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.

[]s
Luca

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.

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