Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Apesar do tópico ser relacionado à aplicações Desktop, eu acho que ele se encaixa melhor na parte de Arquitetura. É o seguinte:
Eu estive durante essa semana conversando com o meu amigo Google para ver se ele tinha informações sobre a utilização do MVC no desenvolvimento de aplicações Desktop, mais especificamente utilizando o Swing. Porém, o Google não me retornou muita coisa e, ainda continuo sem respostas.
Estou no meu último ano de faculdade e pretendo desenvolver um framework MVC para ser utilizado com Swing. Só que eu não sei nem por onde começar!
Estudei a viabilidade desse tipo de arquitetura em uma aplicação Desktop e, naturalmente, a comparação com os frameworks Web existentes são inevitáveis, já que existem milhares de frameworks MVC que são utilizados na criação de aplicações para Web. E criar um framework MVC para auxiliar o desenvolvimento de aplicativos Desktop deve ser algo bem diferente do que construir um framework MVC para Web, pois sabemos que as possibilidades de interação com um aplicativo Desktop são maiores do que costumamos ver em uma aplicação Web, onde *basicamente* se caracteriza por requisições/respostas.
Também pude perceber que praticamente não existe nenhum framework que se propõe a suprir tal falta. Claro que existem algumas (poucas) alternativas existentes, como o JForms.
Encontrei esse post bastante interessante na Internet, que retrata tal limitação e uma possível solução. Gostaria que vocês lessem e compartilhassem suas opiniões e sugestões. Gostaria de disparar aqui uma discussão que ajude a nós mesmos, desenvolvedores, a pensar em uma forma melhor de arquitetar um aplicativo Desktop.
Que tal implementar o JForms no teu TCC? Fale com o Fábio, acredito que exista algum problema (sempre tem algum) que deve ser estudado e implementado para o JForms.
MVC, o termo mais genérico e over-used depois de IoC _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Então, qual a sugestão de vocês? Como vocês costumam trabalhar com uma aplicação Swing, onde o código de negócios está misturado com a complexidade do código que trata os listeners da aplicação? _________________Daniel F. Martins
O Swing internamente é um MVC, mas o MVC que eu acho legal ser implementado é a separação total das camadas.
Tipo se amanha o cliente chegasse pra ele e falasse eu quero colocar o sistema na web usando struts, se realmente for implementado o MVC correto basta mudar a VISAO e reutilizar o resto de código pra colocar a aplicação na web.
Um das principais premissas do MVC é a reutilização de código.
_________________Analista de Sistemas
"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original." Einstein
That's the point!
O que eu estou querendo dizer com essa história de MVC pra cá, MVC pra lá, é dizendo não no padrão MVC por si só, mas uma forma de estruturar aplicações Desktop de modo que consigamos criar sistemas onde o tratamento dos eventos disparados na interface seja claramente separado dos casos de uso.
E Ronald, não estou procurando criar problemas por aqui ao discutir o já discutido MVC, como você salientou. Apesar desse tema já ser mais do que carimbado, você certamente sabe que essa separação costuma ser problemática... _________________Daniel F. Martins
Não não, o meu comentário não era em relação ao seu post, mas ao do Vitor. O Swing não é 'MVC internamente'. Alguns componentes usam uma separação dos dados em um modelo, e todos delegam a renderização para um outro objeto, mas também não é o MVC original do Smalltalk.
Mas já que hoje em dia tudo que se assemelha levemente, só de longe, mais ou menos parecido com isso é chamado de MVC, então deixa pra lá _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Ok! Agora entendi seu ponto de vista. Mas, deixe-me mudar a pergunta inicial..
Vamos comparar o número de frameworks disponíveis que servem para 'separar as coisas', nos ambientes Desktop e Web. Porque existem tantas opções para o ambiente Web, e tão poucas opções para o ambiente Desktop? Quais são as dificuldades de se implementar algo do tipo para facilitar o desenvolvimento de aplicações Desktop? _________________Daniel F. Martins
Como diz a própria Sun: And many Swing users have run across articles saying that Swing is based on something called a "modified MVC (model-view-controller) architecture."
Ok! Agora entendi seu ponto de vista. Mas, deixe-me mudar a pergunta inicial..
Vamos comparar o número de frameworks disponíveis que servem para 'separar as coisas', nos ambientes Desktop e Web. Porque existem tantas opções para o ambiente Web, e tão poucas opções para o ambiente Desktop? Quais são as dificuldades de se implementar algo do tipo para facilitar o desenvolvimento de aplicações Desktop?
Porque desktop em Java não é tão difundido quanto Web. Um dos grandes impecílios é a ausência de uma boa ferramenta para desenhar telas. Graças a deus o NetBeans 5.0 tah aí para suprir essa necessidade.
Eu lembro que, quando eu começei, só o JBuilder tinha ferramenta para desenhar telas. E ainda era muito ruim. Tanto que até hoje eu crio as telas do swing no braço mesmo. _________________Vitor Pamplona
http://vitorpamplona.com @vitorpamplona
Também acredito nisso.. mas será que esse realmente é o único obstáculo? Apesar da programação Desktop não ser tão difundida quanto à programação Web, realmente é muito estranho o fato de existir tão poucas opções.. _________________Daniel F. Martins
Vamos comparar o número de frameworks disponíveis que servem para 'separar as coisas', nos ambientes Desktop e Web. Porque existem tantas opções para o ambiente Web, e tão poucas opções para o ambiente Desktop? Quais são as dificuldades de se implementar algo do tipo para facilitar o desenvolvimento de aplicações Desktop?
Numa aplicação web, cada requisição corre separadamente das outras, assume-se que o servidor é uma máquina parruda que consegue processar diversos contextos em paralelo, e mais que isso, o contexto pode ser reconstuído a cada requisição.
Numa aplicação desktop, a coisa é diferente.
1. Existe uma única thread para a renderização e tratamento de eventos da GUI. O processamento pesado deve ocorrer em outras threads para não travar a interface, mas ao mesmo tempo, qualquer atualização deve ser feita a partir da thread principal (Swing).
2. Os objetos da GUI não são recriados a cada requisição (como numa aplicação web). Isto é bom por um lado, porque você não precisa buscar um monte de dados do banco toda vez, mas por outro lado, você tem que ficar controlando o que é pra ser carregado e o que não é, além de ficar de olho nos memory leaks. Numa aplicação web, você simplesmente carrega tudo, monta a tela, depois espera a GC fazer a limpeza.
3. Frameworks como o Hibernate foram concebidos para uso no paradigma web. Apesar de ser possível usá-los em aplicações desktop, alguns cuidados extras devem ser tomados. Por exemplo, numa aplicação web, os objetos são carregados durante o processamento, usados na montagem da tela, e depois descartados, sendo que a sessão tem uma fronteira bem definida (requisição). Numa aplicação desktop, ou você força um esquema no estilo request-response (para usar o mesmo estilo da web) com camadas bem definidas, ou você faz alguma 'mágica' para tudo funcionar a contento, no esquema do Swing. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
4. Espera-se mais interatividade das interfaces em aplicações desktop. Como as possibilidades são maiores, as exigências acabam sendo maiores também.
Os paradigmas são bem diferentes, pelo menos nas suas formas tradicionais. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
... Numa aplicação desktop, ou você força um esquema no estilo request-response (para usar o mesmo estilo da web) com camadas bem definidas, ou você faz alguma 'mágica' para tudo funcionar a contento, no esquema do Swing.
Você leu o link que eu passei no primeiro post? Um dos comentários desse post faz referência a este framework: http://www.werx.org/[/url], que implementa um tipo de barramento de eventos, onde os eventos transitam por esse barramento, e existem objetos 'tratadores' que capturam os eventos desse barramento, fazendo o tratamento necessário. Essa solução não solucionaria essa limitação de 'engessar' a aplicação à requests e responses? _________________Daniel F. Martins
Eu na verdade não estava considerando a existência ou não de frameworks que façam isso, só estou enumerando as dificuldades que eu vejo.
O framework é interessante, mas não dá pra avaliar sem testar. Quem sabe outra hora
Pra mim, coisas importantes seriam a facilidade de usar o framework, a facilidade de integrá-lo a ferramentas já existentes (matisse, hibernate, etc.), e que ele fosse o menos intrusivo quanto possível. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Eu na verdade não estava considerando a existência ou não de frameworks que façam isso, só estou enumerando as dificuldades que eu vejo.
O framework é interessante, mas não dá pra avaliar sem testar. Quem sabe outra hora
Pra mim, coisas importantes seriam a facilidade de usar o framework, a facilidade de integrá-lo a ferramentas já existentes (matisse, hibernate, etc.), e que ele fosse o menos intrusivo quanto possível.
Essa é a idéia. Estou pensando não em desenvolver um framework que mais se pareça com um canivete-suíço, mas algo simples. Um esquema que eu possa refatorar uma aplicação Desktop para utilizar um conjunto de boas práticas para facilitar a separação entre as camadas, provavelmente utilizando algum tipo de MVC, sei lá.. ainda estou estudando. Pensei na idéia do MVC, de modo a reutilizar (ou adaptar, com poucas mudanças) as configurações do controlador (este que ainda não sei como poderei fazer), para fazer com que uma aplicação, inicialmente projetada para rodar em stand alone seja capaz de ser portada para um ambiente Web, e vice-versa. _________________Daniel F. Martins
Pensei na idéia do MVC, de modo a reutilizar (ou adaptar, com poucas mudanças) as configurações do controlador (este que ainda não sei como poderei fazer), para fazer com que uma aplicação, inicialmente projetada para rodar em stand alone seja capaz de ser portada para um ambiente Web, e vice-versa.
Hum... Não sei se a 'portabilidade desktop-web' seja um objetivo que valha a pena, já que a forma de interação difere bastante entre os dois paradigmas (você iria acabar subutilizando o ambiente desktop para se encaixar ao modelo web). Mas já aproveitar as idéias de frameworks web para facilitar a implementação de aplicações desktop, já seria uma coisa mais útil.
Este projeto do Tim Boudreau (da equipe do netbeans) é bem simples mas ótimo para tirar idéias de facilidade para mapeamento de actions, vale a pena dar uma olhada (tem que baixar do CVS, não tem release ainda): https://actions.dev.java.net/
Outra coisa que você pode procurar são as adaptações do XWork para Swing que existem por aí. Acho que nenhuma está madura o suficiente, mas talvez ajudem a dar idéias. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Concordo com o Ronald mas acredito que seja possível criar uma arquitetura de aplicação que torne a troca frequente entre Web e Desktop, viável. É claro que muita coisa na parte Web tem que existir para criar algo semelhante a parte Desktop, ou vice versa. Exemplo: Contexto por sessão do web ou um HeavyClient no Swing.
Basicamente a diferença é essa: a view da Web é peso pena/peso medio enquanto no Swing é peso médio/peso pesado.
Basicamente a diferença é essa: a view da Web é peso pena/peso medio enquanto no Swing é peso médio/peso pesado.
Não entendi...
Ah, há mais uma opção: embutir na aplicação tanto o browser (JDIC) quanto um servidor web (Jetty), e fazer os dois rodarem no mesmo processo. Daí a aplicação vai realmente ser ao mesmo tempo web e desktop XD _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
Opa, estou considerando a idéia de aproveitar a implementação do XWork e criar um Front Controller, bom, isso no caso de implementar algo parecido com o WebWork.. Porém estou pesquisando por alternativas e estudando quais se tornam mais viáveis/flexíveis.
Se alguém mais tem sugestões ou gostaria de discutir o tópico com a gente, seja bem-vindo _________________Daniel F. Martins
Opa, estou considerando a idéia de aproveitar a implementação do XWork e criar um Front Controller, bom, isso no caso de implementar algo parecido com o WebWork.. Porém estou pesquisando por alternativas e estudando quais se tornam mais viáveis/flexíveis.
Se alguém mais tem sugestões ou gostaria de discutir o tópico com agente, seja bem-vindo
Olá,
Isso é o que o JForms faz hoje.
O que eu e o Avila estamos penando pra pensar uma solucao legal é como fazer o JForms conversar com a GUI sem precisar implementar interfaces do framework.
Por exemplo, hoje pra usar o JForms tu é obrigado a usar os componentes dele, JFTextField, JFLabel, etc. Isso porque esses compoenentes implementam umas interfaces pro JForms se "achar" no bind, mas isso nao é legal porque perdemos o poder das IDE para desenhar a GUI. Entao estamos pensando uma solucao pra resolver esse problema. Na verdade eu e o Avila ja temos uma ideia de como fazer, so que nao colocamos a mao na massa ainda. Se tiver afim de participar ou pegar umas ideias é so falar.
Valeu por participar!! Eu gostaria sim de poder ajudar e trocar idéias com vocês, tanto para clarear a minha cabeça quanto para dar continuidade ao JForms.
Só fazendo algumas perguntas, vocês conseguiram um bom resultado utilizando o XWork para a criação do 'controlador'? Caso essa arquitetura de um Controller 'monolítico' não funcione tão bem quanto em aplicações Web, podemos pensar em algum outro modo para isso..
E quanto ao acoplamento entre o JForms e as classes da aplicação? Quais são suas idéias para evitar esse problema?
Não sou um ultra-fuckin'-expert-java-man, mas estou disposto a ajudar caso minha ajuda seja útil.
Basicamente a diferença é essa: a view da Web é peso pena/peso medio enquanto no Swing é peso médio/peso pesado.
Não entendi...
Quis dizer que a maioria dos softwares Swing tem mais "coisas pra fazer", como vc mesmo disse:
2. Os objetos da GUI não são recriados a cada requisição (como numa aplicação web). Isto é bom por um lado, porque você não precisa buscar um monte de dados do banco toda vez, mas por outro lado, você tem que ficar controlando o que é pra ser carregado e o que não é, além de ficar de olho nos memory leaks. Numa aplicação web, você simplesmente carrega tudo, monta a tela, depois espera a GC fazer a limpeza.
Fora isso tem as telas com processamento pesado no lado do cliente que, se fossem feitas em páginas Web ficariam lentos. Um dia um de meus colegas me disse que enquanto que softwares web possuem basicamente uma boa telinha (HTML) e, no máximo, vários links com processamento no servidor, os softwares desktop possuem várias ações ativadas de várias maneiras com processamentos no servidor e no cliente. A diferença é que na programação Web, joga-se o máximo de processamento possível para o servidor, enquanto que, com softwares desktop, joga-se o máximo possível para a aplicação cliente.
Assumindo que a máquina cliente tem que abrir várias telas Swing, ela não pode ter uma configuração tão básica. Com 128MB de ram já da para colocar vários processos que seriam do servidor nos clientes.
É aí que começam os problemas de portabilidade entre aplicações Web e Desktop. Veja, isso que estamos falando só em Web e Desktop, não podemos esquecer que existem palms, pockets e celulares no jogo.
Tava pensando aqui agora..
Eu sei que uma arquitetura baseada em callbacks é extremamente limitada e tal (também nada muito O.O.), mas não seria possível criar uma variação dessa técnica tipo assim:
* Existe um Front Controller configurado através de um XML (como costumamos ver nos frameworks web que existem por aí). Esse controller é chamado a partir de eventos de interação do usuário com a janela Swing.
* O controlador, por sua vez, invoca a(s) action(s) relacionada(s) e, em seguida, chama o método de callback na view, permitindo que o resultado seja atualizado na view.
O problema é que, em uma aplicação Desktop, um controller não seria invocado somente para injetar os dados de um formulário na Action para estes dados serem processados e os resultados ficarem disponíveis para que a View consiga capturá-los.. essa 'interação' pode ocorrer das formas mais variadas possíveis..
Enfim, pode ser que sim, pode ser que não.. é uma questão de levantar quais costumam ser os tipos de interação mais comuns em uma aplicação Desktop e verificar se essa abordagem funciona bem.
Já usaste o padrão State? Eu acho um padrão indispensável de se usar dentro da camada de controle no MVC, eu não faço uma aplicação desktop sem ele.
Já mandei uma PM para o autor do jforms perguntando se ele usa nesse framework (ainda não tive resposta ou a mensagem falhou...). Um framework MVC que utilizasse State na camada de controle seria extremamente flexível pois poderias definir os estados e as transições destes estados num XML. Imagine que flexível: poderias alterar o fluxo da aplicação sem reprogramar nada. A transferência de objetos entre um estado e outro seria feito através de um objeto de sessão.
Porém isso é bastante limitante.. pois ainda assim eu não estaria garantindo usabilidade, já que na parte que eu utilizo o objeto 'sender', eu estaria amarrando a Action a uma view específica..
Só se utilizarmos interfaces para eliminar este problema, mas dependendo de como isso ser feito, o framework será mais 'intrusivo' e essa definitivamente não é a melhor solução
_________________Daniel F. Martins
Sim! O State é primo (ou seria filho?) do Strategy, a implementação é a mesma. Seria algo como
Uma interface...
Várias implementações...
Um contexto...
Clientes...
Eu sempre uso esse padrão nas aplicações desktop que faço e isso torna o desenvolvimento muito simples e consistente. Se fosse para usar um framework, ele deveria no máximo comportar as interfaces que eu preciso (Estado, Fluxo), senão seria muita intromissão e complicação desnecessária mesmo.
Eu baixei hoje os fontes do JForms, no fim da tarde. E, pelo pouco que vi, já consegui pegar mais ou menos a idéia do framework.. é bem o que eu tenho em mente! Apesar de ainda estar pesquisando outras formas, tenho quase certeza que vai ser algo que segue um raciocínio bem parecido.
Bom, tô indo durmir ae porque senão amanhã eu não aguento o tranco né mas, amanhã eu vou olhar o todo o código do core do JForms e qualquer idéia eu posto aqui.
Baseado no artigo que escrevi aqui no JavaFree e nos design patterns que estão no site do Martin Fowler, eu estou implementando um framework para facilitar o desenvolvimento de pequeno/médio porte usando Swing.
Pra quem tiver interesse em ver como está ficando, acesse esse link:
PS: Não é objetivo desse projeto resolver *todos* os problemas, mas tornar fácil a implementação de funcionalidades que são triviais e chatas de escrever, devido ao código 'duplicadamente macarrônico' (nossa!) e difícil de testar.
O "grosso" da ideia que voce descreve no seu blog eh exatamente o que o genesis jah faz, soh que voce descreveu um subconjunto das funcionalidades suportadas, na verdade, como o fato do genesis jah sincronizar automaticamente o estado do form e da tela e de fazer outras coisas, como habilitar/desabilitar e exibir/ocultar os componentes e de tudo funcionar de forma declarativa com anotacoes.
Nao seria mais interessante contribuir com o genesis do que reinventar a roda?
Seria. Realmente, eu não conhecia o Genesis, mas tá aí um bom projeto.
O que aconteceu pra mim começar a escrever o meu próprio foi a soma de alguns fatores:
* Programar em Swing com aquele monte de listeners junto com o JFrame é muito chato;
* Testar um listener é muito chato;
* Usar frameworks que te forçam a usar implementações diferentes dos componentes-padrão do Swing e/ou mudar o seus POJOs também é muuuito chato;
* Último ano de faculdade, sem nenhuma idéia pra TCC;
Bom.. junta tudo isso e .. voilá! Eis que surge a idéia. A princípio era apenas para apresentar como trabalho de conclusão de curso, mas talvez se torne algo que dê para levar adiante.
Não gosto desse negócio de 'reinventar a roda', mas, nesse caso, foi uma forma de unir o útil ao agradável (ou ao necessário) _________________Daniel F. Martins
* Programar em Swing com aquele monte de listeners junto com o JFrame é muito chato;
* Testar um listener é muito chato;
* Usar frameworks que te forçam a usar implementações diferentes dos componentes-padrão do Swing e/ou mudar o seus POJOs também é muuuito chato;
Pois eh, esses problemas o genesis resolve. A graca eh que ele resolve outros tambem, existe hah mais tempo e as funcionalidades estao mais refinadas por jah ser usado em projetos que estao em producao. Alem disso, suporta duas APIs graficas jah (Swing e Thinlet), SWT vai ser adicionado na proxima release e funciona com Java 1.4.
TriTonE
... talvez se torne algo que dê para levar adiante.
...Nao duvido, mas acredito que seria mais interessante unir forcas. Sim, estou te convidando mesmo a colaborar com o desenvolvimento do genesis Que acha?
Se minha contribuição for útil, posso contribuir sim. A única coisa que me impede de participar mais, tanto do JF qto de projetos como esse é falta de tempo.. o ano que vem eu estarei fora da faculdade (por um bom motivo, espero) e aí fica mais fácil.
Alguém já utilizou, estudou ou conhece o Swing Action Framework?
Acho que me precipitei.... Complementando a informação:
A "JSR 296: Swing Application Framework" está em andamento....
http://jcp.org/en/jsr/detail?id=296 "This JSR will provide a simple application framework for Swing applications. It will define infrastructure common to most desktop applications. In so doing, Swing applications will be easier to create."
".13 Please describe the anticipated schedule for the development of this specification.
The intention is to deliver this JSR as a component of Java SE 7 (code name "Dolphin"). Early Draft Review would occur in the second half of 2006, Public Review in the first half of 2007, and Proposed Final Draft in the second half of
2007."
Tah me parecendo muito blá-blá-blá para pouca coisa prática.. (Ou pelo menos pelo que vi na apresentação do Cara. Se o melhor que ele tinha para mostrar era aquilo, credo... )
A única coisa legal que eu vi do framework é facilitar a entrada de ResourceBundles específicas como Cores e tudo mais... Mas nada que uma classe Utilitária não resolva. Nada de muito original para variar...
TriTonEPosts:1576
Apesar do tópico ser relacionado à aplicações Desktop, eu acho que ele se encaixa melhor na parte de Arquitetura. É o seguinte:
Eu estive durante essa semana conversando com o meu amigo Google para ver se ele tinha informações sobre a utilização do MVC no desenvolvimento de aplicações Desktop, mais especificamente utilizando o Swing. Porém, o Google não me retornou muita coisa e, ainda continuo sem respostas.
Estou no meu último ano de faculdade e pretendo desenvolver um framework MVC para ser utilizado com Swing. Só que eu não sei nem por onde começar!
Estudei a viabilidade desse tipo de arquitetura em uma aplicação Desktop e, naturalmente, a comparação com os frameworks Web existentes são inevitáveis, já que existem milhares de frameworks MVC que são utilizados na criação de aplicações para Web. E criar um framework MVC para auxiliar o desenvolvimento de aplicativos Desktop deve ser algo bem diferente do que construir um framework MVC para Web, pois sabemos que as possibilidades de interação com um aplicativo Desktop são maiores do que costumamos ver em uma aplicação Web, onde *basicamente* se caracteriza por requisições/respostas.
Também pude perceber que praticamente não existe nenhum framework que se propõe a suprir tal falta. Claro que existem algumas (poucas) alternativas existentes, como o JForms.
Encontrei esse post bastante interessante na Internet, que retrata tal limitação e uma possível solução. Gostaria que vocês lessem e compartilhassem suas opiniões e sugestões. Gostaria de disparar aqui uma discussão que ajude a nós mesmos, desenvolvedores, a pensar em uma forma melhor de arquitetar um aplicativo Desktop.
Espero ter a participação de todos.
[]'s
_________________Daniel F. Martins
vfpampPosts:6098
Swing é internamente, um MVC
Que tal implementar o JForms no teu TCC? Fale com o Fábio, acredito que exista algum problema (sempre tem algum) que deve ser estudado e implementado para o JForms.
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
ronaldtmPosts:2317
MVC, o termo mais genérico e over-used depois de IoC
_________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
TriTonEPosts:1576
Então, qual a sugestão de vocês? Como vocês costumam trabalhar com uma aplicação Swing, onde o código de negócios está misturado com a complexidade do código que trata os listeners da aplicação?
_________________Daniel F. Martins
dcmaximoPosts:33
O Swing internamente é um MVC, mas o MVC que eu acho legal ser implementado é a separação total das camadas.
Tipo se amanha o cliente chegasse pra ele e falasse eu quero colocar o sistema na web usando struts, se realmente for implementado o MVC correto basta mudar a VISAO e reutilizar o resto de código pra colocar a aplicação na web.
Um das principais premissas do MVC é a reutilização de código.
_________________Analista de Sistemas
"A mente que se abre a uma nova idéia jamais voltará ao seu tamanho original." Einstein
TriTonEPosts:1576
That's the point!
O que eu estou querendo dizer com essa história de MVC pra cá, MVC pra lá, é dizendo não no padrão MVC por si só, mas uma forma de estruturar aplicações Desktop de modo que consigamos criar sistemas onde o tratamento dos eventos disparados na interface seja claramente separado dos casos de uso.
E Ronald, não estou procurando criar problemas por aqui ao discutir o já discutido MVC, como você salientou. Apesar desse tema já ser mais do que carimbado, você certamente sabe que essa separação costuma ser problemática...
_________________Daniel F. Martins
ronaldtmPosts:2317
Não não, o meu comentário não era em relação ao seu post, mas ao do Vitor. O Swing não é 'MVC internamente'. Alguns componentes usam uma separação dos dados em um modelo, e todos delegam a renderização para um outro objeto, mas também não é o MVC original do Smalltalk.
Mas já que hoje em dia tudo que se assemelha levemente, só de longe, mais ou menos parecido com isso é chamado de MVC, então deixa pra lá
_________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
TriTonEPosts:1576
Ok! Agora entendi seu ponto de vista.
Mas, deixe-me mudar a pergunta inicial..
Vamos comparar o número de frameworks disponíveis que servem para 'separar as coisas', nos ambientes Desktop e Web. Porque existem tantas opções para o ambiente Web, e tão poucas opções para o ambiente Desktop? Quais são as dificuldades de se implementar algo do tipo para facilitar o desenvolvimento de aplicações Desktop?
_________________Daniel F. Martins
vfpampPosts:6098
Quase todos os componentes neh?
Como diz a própria Sun: And many Swing users have run across articles saying that Swing is based on something called a "modified MVC (model-view-controller) architecture."
http://java.sun.com/products/jfc/tsc/articles/architecture/
_________________Vitor Pamplona
http://vitorpamplona.com
@vitorpamplona
vfpampPosts:6098