Qual é a sua recomendação para arquitetar aplicações GWT? MVC, MVP ou solução de mensagens personalizado?

Question

Eu só comecei um novo projeto GWT para um cliente e eu estou interessado em ouvir a experiência das pessoas com várias arquiteturas GWT MVC. Em um recente projeto, eu usei tanto GXT MVC , bem como uma solução de mensagens personalizado (com base em da Appcelerator MQ ). GXT MVC trabalhou OK, mas parecia um exagero para GWT e foi difícil fazer o trabalho com o histórico do navegador. Já ouvi falar de PureMVC e GWTiger , mas nunca utilizado. Nossa solução MQ costume funcionou muito bem, mas tornou difícil testar componentes com JUnit.

Além disso, eu ouvi que o Google Wave (uma aplicação GWT) é escrito usando um padrão Model-View-Presenter. A aplicação de exemplo MVP foi recentemente publicado, mas olhando para o código, ele doesn 't parecer que intuitiva.

Se você estivesse construindo um novo aplicativo GWT, que arquitetura você usaria? Quais são os prós e contras de sua escolha?

Obrigado,

Matt

Answer 1

É importante notar que o Google finalmente escrito um tutorial para desenhar usando a arquitetura de MVP. Ele esclarece muitos dos elementos do Google I / O talk listados acima. Dê uma olhada: https://developers.google.com/web-toolkit/articles / mvp-arquitetura

Answer 2

Estou feliz esta pergunta foi feita, porque GWT desperatley precisa de um rails-como forma de estruturar uma aplicação. Uma abordagem simples baseada nas melhores práticas que irá trabalhar para 90% de todos os casos de uso e permite super fácil capacidade de teste.

Nos últimos anos, tenho vindo a utilizar a minha própria implementação de MVP com uma vista muito passiva que escraviza-se a tudo o que o apresentador lhe diz para fazer.

A minha solução consistiu no seguinte:

• uma interface por widget de que definem os métodos para controlar a aparência visual
• uma classe de implementação que pode ser um Composite ou usar uma biblioteca de widgets externa
• Um apresentador central para uma tela que hosts n pontos de vista que são constituídos por M de widgets
• um modelo central por tela que contém os dados associados com a aparência visual atual
• aulas ouvinte genéricos como "SourcesAddEvents [CustomerDTO]" (o editor não como os símbolos reais para os genéricos java aqui, então eu usei thoe parênteses), porque senão você vai ter muita as mesmas interfaces que apenas diferem pelo tipo

As Visualizações obter uma referência para o apresentador como seu parâmetro de construtor, para que eles possam iniciar os seus eventos com o apresentador. O apresentador vai alças esses eventos e notificar outros widgets / pontos de vista e ou chamada GWT-RPC que em caso de sucesso coloca o seu resultado no modelo. O modelo tem um típico "propriedade [Lista [String]] nomes = ...." mecanismo de mudança de propriedade ouvinte que está registrado com o apresentador para que a atualização de um modelo por um pedido GWT-RPC vai para todos os views / widgets que está interessado.

Com este appraoch eu ter começado muito fácil testability com EasyMock para os meus AsynInterfaces. Eu também tenho a capacidade de facilmente trocar a implementação de uma visão / widget, porque tudo que eu tive que reescrever era o código que notificou o apresentador de algum evento -., Independentemente do widget subjacente (Button, links, etc)

Problemas com a minha abordagem:

• Minha implementação atual torna difícil para sincronizar os valores de dados entre os modelos de centrais de diferentes telas. Digamos que você tenha uma tela que exibe um conjunto de categorias e uma outra tela que permite adicionar / editar esses itens. Atualmente é muito difícil para propagar esses eventos de alteração em todo os limites das telas, porque os valores são armazenados em cache nesses modelos e é difícil de encontrar o nosso se algumas coisas estão sujas (teria sido fácil em um tradicional Web1.0-html -dumb-terminal tipo de cenário com serverside caching declarativa).
• Os parâmetros do construtor dos pontos de vista permitir o teste super-fácil, mas sem um quadro de dependência por injeção sólida, um vai ter algum código de fábrica / setup FEIO dentro "onModuleLoad ()". Na época, eu comecei isso, eu não estava ciente do Google GIN, então quando eu refatorar meu aplicativo, eu vou usar isso para se livrar desse clichê. Um exemplo interessante é o "HigherLower" jogo dentro do GIN-Tronco.
• Eu não recebi História certo da primeira vez, por isso é difícil de navegar de uma parte do meu aplicativo para outro. Minha abordagem não tem conhecimento de História, que é uma grave recessão.

As minhas soluções para esses problemas:

• Use GIN para remover o clichê de configuração que é difícil de manter
• Enquanto se move a partir Gwt-Ext para GXT, use seu framework MVC como um EventBus para montar / desmontar telas modulares, para evitar os problemas de cache / sincronização
• Pense em algum tipo de "Place" -Abstraction como Ray Ryan descreveu em sua palestra no I / O 09, que preenche a Event-Gap entre GXT-MVC e abordagem GWTs-Hitory
• Use MVP para widgets para acesso a dados isolado

Sumário:

Eu não acho que pode-se usar uma abordagem única "MVP" para um aplicativo inteiro. Um precisa definitivamente a história de app-navegação, uma EventBus como GXT-MVC para anexar / telas de desanexação e MVP para permitir a fácil testes de acesso a dados para widgets.

Assim, proponho uma layeabordagem vermelho que combina estes três elementos, pois acredito que o "one-evento-mvp-system" -solution vai funcionar. Navegação / Screen-Colocar / Data-Access são três preocupações separadas e vou refazer meu aplicativo (movimento para GXT) nos meses seguintes para utilizar todos os três eventos-estruturas para cada preocupações separadamente (melhor ferramenta para o trabalho). Todos os três elementos não precisa estar ciente do outro. Eu sei que a minha solução se aplica somente para GXT-projectos.

Ao escrever grandes aplicações GWT, eu sinto que eu tenho que reinventar algo como Primavera-MVC no cliente, que realmente é uma porcaria, porque leva muito tempo e cérebro-poder de cuspir algo elegante como Spring MVC. GWT precisa de um quadro aplicativo muito mais do que essas pequenas JS-otimizações que o compilador de caras trabalhar tão duro.

Answer 3

Aqui está uma apresentação recente do Google IO na architecting seu GWT aplicativo .

Aproveite.

-JP

Answer 4

Se você está interessado em usar a arquitetura MVP, você pode querer dar uma olhada em GWTP: http://code.google.com/p/gwt-platform/ . É um framework de código aberto MVP eu estou trabalhando, que suporta muitas características interessantes GWT, incluindo a divisão de código e gerenciamento de histórico, com um simples API baseada em anotações. É bastante recente, mas já está sendo usado em uma série de projetos.

Answer 5

Você deve ter um olhar para GWT Portlets . Nós desenvolvemos o GWT Portlets Framework, enquanto trabalhava em um aplicativo grande HR Portal e agora é livre e open source. Do site do GWT Portlets (hospedado no Google Code):

O modelo de programação é um pouco semelhante a escrever portlets JSR168 para um servidor de portal (Liferay, JBoss Portal etc.). O "portal" é o seu aplicativo construído utilizando o framework GWT portlets como uma biblioteca. A funcionalidade do aplicativo é desenvolvido como portlets de baixo acoplamento cada um com um DataProvider lado do servidor opcional.

Cada Portlet sabe como exteriorizar seu estado em uma subclasse serializável PortletFactory (momento / DTO / padrão de fábrica) fazendo funcionalidades importantes possível:

operações
• CRUD são manipulados por um único GWT RPC para todos os portlets
• O layout de Portlets em uma "página" pode ser representado como uma árvore de WidgetFactory de (uma interface implementada por PortletFactory)
• Árvores da WidgetFactory de pode ser serializado e marshalled de / para XML no servidor, para layouts loja GUI (ou "páginas") na página arquivos XML

Outras características importantes do quadro estão listados abaixo:

• As páginas podem ser editadas no navegador em tempo de execução (por desenvolvedores e / ou usuários) usando o editor de layout de quadro
• Portlets estão posicionados absolutamente assim pode usar regiões de rolagem
• Portlets são configuráveis, indicar quando eles são de carga movimentada para a exibição automática de "carregamento giratório" e pode ser maximizada
• temáticos os widgets, incluindo uma caixa de diálogo estilo, a CSS estilo de substituição botão, pequenos toolbuttons e um menu de modelo HTML impulsionado

GWT Portlets é implementado em código Java e não quebra nenhum bibliotecas Javascript externas. Ele não impõe qualquer quadro do lado do servidor (por exemplo, Primavera ou J2EE), mas é projetado para trabalhar bem em conjunto com tais estruturas.