Arquitetura para desenvolvimento MVC com Swing

Eu prefiro a primeira, mas acho que o controller nao precisa conhecer a tela, ou qualquer alteracao de tecnologia na view fica comprometida. No seu caso, a primeira vista, optaria pela primeira opcao e iria refatorando pra tirar a referencia à View dos controllers.

Sempre que o assunto é a interação entre componentes envolvidos no MVC é complicado opinar, pois normalmente é algo muito subjetivo. Mas quando percebemos que existe algo que deixa o software de forma ‘gelatinosa’ (Mexe aqui … altera ali), algo está errado e possivelmente é relacionado a forma de comunicação entre as camadas.

Particularmente, repito, no meu próprio ponto de vista, rsrsrrs, acredito que a segunda forma deixe as camadas mais bem definidas e a interação entre elas mais modularizadas. Eu optaria por esta solução…

Att…

Felagund:

Pessoal to abrindo uma discussão em uma dúvida que surgiu aqui no serviço.

Utilizamos em dois sistemas arquiteturas diferentes.

• 1 deles utiliza o observer, ou seja a a tela tem um controlador, o controlador observa n telas, e por meio de atualização envia a informação para as telas solicitadas.
• O outro utiliza listeners, alguns listeners padrões que comunicam a tela e o controlador, para processar a informação.

O problema que nos fez adotar a segunda opção foi a dependencia circular para o primeiro caso. A tela possui a referencia do controlador e o controlador por usa vez possui a referencia da tela, porém esse modelo é o mais simples e intuitivo de desenvolver.

o Segundo se torna um pouco mais xato o desenvolvimento, mas não existe a dependencia circular.

Qual dos metodos vcs acham o melhor?

LEMBRANDO é um desenvolvimento Swing distribuido, ou seja a parte do banco fica em um modulo EJB.

Olá Falegund, tudo bem?

Eu prefiro o listener. A dependência circular é realmente um problema chato. Com implementações bem feitas e com uma boa equipe, os listerners serão de grande ajuda.
=)

Ps.: Eu já trabalhei em um projeto que utilizava arquitetura swing com EJB. Eram projetos da VALE. Até mais.

O Controller usa o padrão observer, ou seja ele observa a tela (extends Observable), por meio do metodo notify e setChanged ele notifica a tela as auterações.

O uso de Listener tem alguns problemas ocmo por exemplo algumas telas tem cerca de 3 a 4 listeners, que as vezes dificultam a manutenção, nem sempre se torna viavel, as vezes eu forço um interface extender a outra.

Notei uma melhora de performance no sistema com Listener, porém o sistema de listener usa postgre e o outro usa oracle, a diferença dos bancos tbm muda, o oracle é mais lento :P.

porém usando o Profiler o com listener deixa bem menos recurso em memoria.