Pergunta

Você já tentou usar MVC ou qualquer outro padrão de interface do usuário para o código do cliente GWT. Quais são as armadilhas / vantagens que você enfrentou em diferentes abordagens?

Foi útil?

Solução

Eu acho que você precisa para tratar GWT como qualquer outro framework de interface do usuário, como Swing, cacau, etc. Tudo isso faz sentido nessas estruturas em termos de MVC (ou outros paradigmas) faz sentido em GWT também. Acho que às vezes as pessoas tomam a coisa MVC longe demais, e eu gosto da maneira como ele funciona em Cocoa mais do que a maioria dos frameworks. Você cria um ponto de vista, você tem um ViewController que controla todo o comportamento da vista, e então você tem objetos de modelo com todos os seus dados. Eu não acho que você precisa ser dogmática sobre onde toda a sua lógica de negócios é, ele só precisa ser onde faz sentido.

Em termos de armadilhas, a principal delas você vai correr em é que GWT é puramente uma tecnologia front-end, então tecnicamente o back-end está sentado em um algum lugar do servidor. Eu não vejo isso como sendo muito diferente de escrever uma aplicação swing cliente servidor, que armazena de dados no algum lugar nuvem. A diferença é que GWT é compilado para baixo em javascript, e tem todas as limitações de uma aplicação web javascript, então haverá algumas coisas que você simplesmente não pode fazer na extremidade dianteira. Digamos, por exemplo, você quer criar um PDF e mostrar isso para o usuário, você não pode fazer isso em GWT, você precisa chamar o back-end para fazer isso por você. Em um aplicativo do balanço, por outro lado, você provavelmente poderia usar itext e fazê-lo no lado do cliente.

Outras dicas

O padrão MVC para GWT é discutido nesta questão , que também tem um link para este blog .

A única coisa que eu gostaria de acrescentar é que o código do lado do cliente em sua totalidade pode ser considerado o "V" em "MVC", o que pode alterar a forma como você olha para ele. Pensando no código do lado do cliente como seu próprio componente MVC aninhada, bem, é o Java, é orientada a objeto, para que possa ser concebido tanto como um aplicativo Swing. Eu acho que é a sua vantagem para puxar o máximo de código controlador fora da vista quanto possível para lidar com as coisas GWT RPC. O modelo é, por vezes, mais problemático, porque você pode ter que decidir se deseja-lo no servidor em vez do cliente. Ou criar um proxy Modelo, etc.

http://code.google.com/p/gwt-mvc/ poderia ajudá-lo.

As vantagens são:

  • fácil de ler controlador
  • Gestão História Tokens
  • Os controladores são testble com JMock (mas não GwtTestCase)
  • hierárquica MVC
  • herança simples para iniciar a codificação sua opinião, controladores e modelos.

Você já tentou GWTruts ( http://sourceforge.net/projects/gwtruts/ ) ? É também uma fonte aberta quadro GWT MVC que separam View e Controller em GWT

Usando algum tipo de tipo de padrão MVC / MVP é realmente importante quando aplicativos GWT ir além da menor projeto mais você controle apenas solta do que está acontecendo.

Além do que já foi mencionado, há também a implementação da GXT MVC que eu olhei aqui: http://www.bristol-gtug.org/?p=45

Esta palestra no Google IO ano passado começou um monte de gente fora do pensamento sobre MVC / MVP no GWT: http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html .

Eu observei recentemente que há também agora um tutorial sobre a arquitetura MVP na documentação do GWT que é um bom começo: http://code.google.com/webtoolkit/doc/latest/tutorial/mvp-architecture.html

Você poderia dar uma olhada em JetPad-Mappers, um framework MVC minimalista desenvolvido na JetBrains e utilizado em vários produtos (atualmente inéditas).

Disclaimer, eu estou envolvido no desenvolvimento deste quadro.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top