Aplicação desktop e web. Existe framework?

Emilio o próprio MVC é quem faz isso para você. Exsitem diversos frameworks que implementam a idéia do mvc por debaixo dos panos…porém vc pode ver que ele por sí só já faz essa separação. Onde

MODELO = Ficariam suas classes de negócio, acesso ao banco, javabeans, validadores, etc…
CONTROLER = seria o responsável por chamar a classe certa no seu modelo
VIEW = seria a camada de visualização podendo ser web, desktop, mobile, etc…

O interessante é fazer um modo que independente da camada de VIEW todas chamem uma mesma classe de controller, nem que para isso vc precise criar algo entre a VIEW e seu CONTROLER.

Emilio o próprio MVC é quem faz isso para você. Exsitem diversos frameworks que implementam a idéia do mvc por debaixo dos panos…porém vc pode ver que ele por sí só já faz essa separação. Onde

MODELO = Ficariam suas classes de negócio, acesso ao banco, javabeans, validadores, etc…
CONTROLER = seria o responsável por chamar a classe certa no seu modelo
VIEW = seria a camada de visualização podendo ser web, desktop, mobile, etc…

O interessante é fazer um modo que independente da camada de VIEW todas chamem uma mesma classe de controller, nem que para isso vc precise criar algo entre a VIEW e seu CONTROLER.

As classes Controller do modelo MVC de Desktop e Web são totalmente diferentes

Na web por exemplo para os controller controller você usa Servlet ou Managed Beans(JSF) responsáveis pelas actions entre outros requisições

No desktop você usa os ActionListener, KeyListener e demais eventos na classe controller

Então no meu ponto de vista não há como você desenvolver uma uníca controller tanto para WEB e Desktop visto que classes e comportamentos são direferentes

As únicas classe que realmente qe dão para usar são as MODELS

Abraços

Lembrem-se: controler e view são intimamente ligadas, para cada view um controller diferente.
A única coisa que jamais deve mudar é o model. Na verdade ele É o sistema, a view é “somente” uma representação gráfica desse cara.

Paulo em qual documentação você leu que MVC depende do tipo da aplicação ??? Onde esta escrito que se for Web é um controller e se for Swing é outro controller ???

Veja bem, MVC é uma idéia abstrata, cabendo ao desenvolvedor aplicá-la em seu sistema. Se eu tivesse essa mesma necessidade do nosso amigo acima, eu iria usar um único controller para toda a aplicação. (Posso te garantir que o faria assim).

Quando você fala de managed-bean já esta entrando no conceito de frameworks, e nossa aplicação não pode ter depêndencia de um framework, ou é essa a sua idéia ??? Será que aqueles que construíram um sistema engessado com Struts 1 e EJB 2 se deram bem ??? E agora não conseguem implementar um JSF com EJB 3 sem que haja a necessidade de alterar um milhão de classes !!!

Acho que um bom arquiteto seria capaz de criar meios de uma comunicação única entre qq camada da view com as outras duas camadas.

Entendo…

Estava pensando em usar o padrão de projeto decorator p/ resolver o problema da view.
Bom, estarei estudando uma forma de como ter o maior índice de reusabilidade.

Obrigado a todos.

Não quis dizer que uma controller na WEB um e no Desktop e outro. Eu disse que a forma como você vai implementar a classe controller é diferente, as aplicações desktop usam eventos como eu citei oas ActionListener, KeyListener já na Web também a forma como vai implementar esses eventos as ações de requisões são diferentes.

Sim o conceito de MVC é abstrato e como você disse cabe o desenvolvedor aplicar em seu sistema Desktop ou Web. Eu não consigo ver uma forma de usar uma uníca controller tanto para web quanto para desktop.

Sim dessa forma estaremos usando frameworks. Vejo da seguinte forma se um desenvolverdor que um usou EJB2 concerteza ao migrar para um EJB3 irá ter que alterar várias classes, Não trabalhei com EJB2, estou utilizando EJB3, mas já vi algumas coisas usando EJB2 e pelo que vi a migração deve ser trabalhosa.
Quando utilizamos JSF+ManagedBeans+EJB já estamos aplicando o conceito de MVC.

Atualmente estou desenvolvendo uma aplicação utilizando EJB3+Glassfish+JSF+JPA+Swing. Os EJBs criados serão os mesmo a ser utilzados tanto na Web quanto no Desktop. Agora as classes controler são diferentes já que o contexto para WEB na web no caso os ManagedBeans e Desktop na controller terei meus ActionListener, KeyListener e outros eventos. E veja que ambas as classes controller irão utilizar o mesmo componente EJB

Tchello
Lembrem-se: controler e view são intimamente ligadas, para cada view um controller diferente.
A única coisa que jamais deve mudar é o model. Na verdade ele É o sistema, a view é “somente” uma representação gráfica desse cara.

É como o Tchello disse a controller e a view estão intimamente ligadas e jamais a model deve mudar

Emilio

Você pode usar a arquitetura Java EE. Se você estiver utilizando Netbeans você pode optar pelo servidor de aplicação Glassfish.
Eu utilizo o Glassfish + EJB3 + JPA + HIBERNATE como provider do JPA + SQL SERVER. E para minhas viewa utilizo Swing e JSF para web
Da uma pesquisa sobre JEE + EJB3 + JPA

Abraços

Paulo no caso exposto nosso contoller não deveria receber requests o actions-listeners já que estes estão intimamente ligado ao tipo de arquitetura.

O ideal seria ter um controller para web e um para desktop, onde ambos poderiam invocar um segundo controller que seria responsável por fazer as chamadas e retornar o esperado. Dessa maneira haveriam dois controllers um centralizado ( FRONT-CONTROOLER ) e outro responsável pela view específica.

Essa seria uma maneira de aplicar esses conceitos. Ou ainda usar um ApplicationService, Facade ou outro pattern qualquer que garanta a mesma chamada para ambas as views sempre trafagendo POJO e não requisições ou eventos.

Paulo no caso exposto nosso contoller não deveria receber requests o actions-listeners já que estes estão intimamente ligado ao tipo de arquitetura.

O ideal seria ter um controller para web e um para desktop, onde ambos poderiam invocar um segundo controller que seria responsável por fazer as chamadas e retornar o esperado. Dessa maneira haveriam dois controllers um centralizado ( FRONT-CONTROOLER ) e outro responsável pela view específica.

Essa seria uma maneira de aplicar esses conceitos. Ou ainda usar um ApplicationService, Facade ou outro pattern qualquer que garanta a mesma chamada para ambas as views sempre trafagendo POJO e não requisições ou evento

Mais esta é a maneira correta de se fazer ter um controller web e outro desktop. Mesmo usando o padrão Front-Controller teriamos que ter duas classes controller.

Eu por exemplo, nas minhas aplicações desktop eu não implemento nenhum código na view, já que este é apenas para possuir os componentes, a regra das actions listeners deixo tudo na controller, que por sua vez faz a chamada a model que por sua vez atualiza a view

Abraços

Giulliano:

Paulo no caso exposto nosso contoller não deveria receber requests o actions-listeners já que estes estão intimamente ligado ao tipo de arquitetura.

O ideal seria ter um controller para web e um para desktop, onde ambos poderiam invocar um segundo controller que seria responsável por fazer as chamadas e retornar o esperado. Dessa maneira haveriam dois controllers um centralizado ( FRONT-CONTROOLER ) e outro responsável pela view específica.

Essa seria uma maneira de aplicar esses conceitos. Ou ainda usar um ApplicationService, Facade ou outro pattern qualquer que garanta a mesma chamada para ambas as views sempre trafagendo POJO e não requisições ou eventos.

Tchello muito bom o seu ponto de vista, mas um controller genérico existe sim e é muito útil. Quando ele não atende às minhas necessidades eu implemento um específico estendendo o principal. Agora ele não tem nenhuma característica de facade já que o controller tem o papel de saber fazer a chamada para o model atráves de algum parâmetro (ou de algum outro jeito), diferente de um facade que serve para fazer chamadas de granularidade alta em nossos domínios de negócio. São patterns completamente diferentes.

Paulo a maneira que você implementa seu controller está correta. O que eu sugeri aqui foi realmente ter um segundo controller ou um facade (tb pode ser) que faça as chamadas ao nosso model. O que não pode acontecer é nosso model receber coisas específicas de uma arquitetura ou de algum framework.

[]'s

Giulliano:

Tchello muito bom o seu ponto de vista, mas um controller genérico existe sim e é muito útil. Quando ele não atende às minhas necessidades eu implemento um específico estendendo o principal. Agora ele não tem nenhuma característica de facade já que o controller tem o papel de saber fazer a chamada para o model atráves de algum parâmetro (ou de algum outro jeito), diferente de um facade que serve para fazer chamadas de granularidade alta em nossos domínios de negócio. São patterns completamente diferentes.

Paulo a maneira que você implementa seu controller está correta. O que eu sugeri aqui foi realmente ter um segundo controller ou um facade (tb pode ser) que faça as chamadas ao nosso model. O que não pode acontecer é nosso model receber coisas específicas de uma arquitetura ou de algum framework.

[]'s

Exatamente, são coisas bastantes distintas.
Na minha humilde opinião não deveria existir controlers genéricos, uma vez que o próprio modelo MVC diz que, como citei acima, view e controler são intimamente ligadas, lembrando que cabe ao controler conhecer tanto o model quanto a view, para traduzir para a view chamdas do model. Ou seja, se o controler conhece a view como podemos ter um controler genérico?
Sendo assim ainda acredito que esse controler genérico comporta-se de forma como um façade, ou algum business-delegate, que podem ser confundidos com facilidade também.
veja: http://www.guj.com.br/posts/list/38657.java

ps: estou adorando(de verdade mesmo) essas discussões sobre arquitetura, gostaria muito que houvessem mais tópicos assim no guj, preciso aguçar minhas “técnicas”.

Tchello

Exatamente, são coisas bastantes distintas.
Na minha humilde opinião não deveria existir controlers genéricos, uma vez que o próprio modelo MVC diz que, como citei acima, view e controler são intimamente ligadas, lembrando que cabe ao controler conhecer tanto o model quanto a view, para traduzir para a view chamdas do model. Ou seja, se o controler conhece a view como podemos ter um controler genérico?
Sendo assim ainda acredito que esse controler genérico comporta-se de forma como um façade, ou algum business-delegate, que podem ser confundidos com facilidade também.
veja: http://www.guj.com.br/posts/list/38657.java

ps: estou adorando(de verdade mesmo) essas discussões sobre arquitetura, gostaria muito que houvessem mais tópicos assim no guj, preciso aguçar minhas “técnicas”.

Concordo com o Tchello acho que também não deveria existir controllers genéricos, já que a view e a controller estão ligadas. Também vejo esse controller genérico como um Facade, que tornaria totalmente desnecessário, já que teremos dois controller distintos um para WEB e outro para Desktop. Os unícos componentes do MVC que se pode usar é a Model tando para web quanto para desktop.

paulofafism:

Tchello

Exatamente, são coisas bastantes distintas.
Na minha humilde opinião não deveria existir controlers genéricos, uma vez que o próprio modelo MVC diz que, como citei acima, view e controler são intimamente ligadas, lembrando que cabe ao controler conhecer tanto o model quanto a view, para traduzir para a view chamdas do model. Ou seja, se o controler conhece a view como podemos ter um controler genérico?
Sendo assim ainda acredito que esse controler genérico comporta-se de forma como um façade, ou algum business-delegate, que podem ser confundidos com facilidade também.
veja: http://www.guj.com.br/posts/list/38657.java

ps: estou adorando(de verdade mesmo) essas discussões sobre arquitetura, gostaria muito que houvessem mais tópicos assim no guj, preciso aguçar minhas “técnicas”.

Concordo com o Tchello acho que também não deveria existir controllers genéricos, já que a view e a controller estão ligadas. Também vejo esse controller genérico como um Facade, que tornaria totalmente desnecessário, já que teremos dois controller distintos um para WEB e outro para Desktop. Os unícos componentes do MVC que se pode usar é a Model tando para web quanto para desktop.