Je travaille depuis un an maintenant sur une application GWT, et nous n'avons jamais ressenti la nécessité d'utiliser l'un de ces cadres ou outils.
Donc, je me sens probablement absent. P>
Nous le faisons "code derrière" style. p>
Voici un exemple simple sur la manière dont nous construisons notre code: p>
mypanel.ui.xml: p>
@UiField
LabelElement label;
@UiField
TextBox box;
@UiField
Button button;
MyBean myBean;
Messages messages = GWT.create(Messages.class);
MyServiceAsync myServiceAsync = GWT.create(MyService.class);
...
protected void i18n() {
label.setInnerText(messages.label());
button.setText(messages.button());
}
...
@UiHandler("box")
void box_onValueChange(ValueChangeEvent<String> event) {
myBean.setText(event.getValue());
}
@UiHandler("button")
void button_onClick(ClickEvent event) {
myServiceAsync.sendData(myBean, new AsyncCallback<MyResponse>() {
@Override
public void onSuccess(ReponseDispoBean result) {
Window.alert(result.message());
}
@Override
public void onFailure(Throwable caught) {
Window.alert(caught.getMessage());
}
});
}
4 Réponses :
La seule chose que je pourrais vous suggérer de jeter un coup d'oeil est requisFactory vs GWT RPC. Il n'exige pas que des objets soient sérialisables et dispose de nombreuses améliorations de performances, telles que l'envoi que des diff sur le fil.
Nous utilisons également le modèle clientfactory qui ressemble à Gin. Nous utilisons cela pour injecter une classe client en fonction du type de périphérique utilisé (tablette, mobile, bureau).
MVP sépare simplement la logique à partir du code de la vue et aide à exécuter le test en JVM au lieu d'utiliser Slow Gwttestcase.
Les éditeurs permettent de lier les propriétés de l'objet aux champs de saisie. Cela rend le code à copier de et en entrant des champs dans vos objets obsolètes.
gin aide à filer vos objets. Encore une fois, cela facilite beaucoup les tests. Vous pouvez câbler vos objets par vous-même de cause, mais pourquoi devriez-vous faire cela si Gin le fait automatiquement pour vous?
DemandeFactory est un remplaçant pour l'approche RPC et est plus centrée sur les données. Il vous aide à aller chercher des données dans le fonctionnement par lots et utilise l'utilisation de DTO obsolète. Vous pouvez vous causer de bâton avec l'approche RPC. Mais il y a des inconvénients. Vous devez créer une serveur pour chaque service ou vous pouvez utiliser le modèle de commande. Cela conduit au problème, que vous devez créer une action, une réponse et un service de traitement pour une demande très demandée. C'est beaucoup de code à entretenir.
Votre approche est ok. En fait, j'ai commencé beaucoup de mes projets prototypes tels que celui-ci (au lieu d'utiliser des tests GWT, pour de tels projets, j'utilise simplement gwttestcase). Et vous savez, parfois c'est tout ce qui est nécessaire, et tout le reste ne ferait qu'une complexité! Donc, ce n'est pas seulement correct pour les prototypes, mais peut vraiment travailler très bien pour de vrais projets.
Mais plus souvent, il s'avère que je veux réutiliser des composants et les rendre plus configurables. Et c'est le moment où je refacteur à MVP. Et Gin si je ne les ai pas déjà (en fait, je commence habituellement tous les projets avec Gin).
Vous pouvez donc ajouter ces choses, quand vous découvrez un besoin pour eux ou un certain avantage (pas parce qu'ils sont théoriquement excellents ou «hanche»).
Au fait, je n'utilise pas l'approche de bus d'événement (à l'exception des petits ensembles d'événements bien définis), car la complexité des systèmes d'événements explose généralement.
De même à DI, comme pour Demandactory (RF), eh bien, c'est un protocole client-serveur différent de GWT-RPC, avec son propre ensemble de fonctionnalités et de limitations. Si vous n'avez pas de problème avec GWT-RPC, vous ne devriez pas changer (bien que je vous recommande de regarder ce que RF est). Pour moi, la principale caractéristique de RF est que c'est un protocole (basé sur JSON) plus qu'une API: les classes sur le client et le serveur ne doivent pas nécessairement être exactement identiques, à condition qu'ils soient compatibles suffisamment compatibles / em> que le client et le serveur se comprennent (ajoutez une propriété, modifiez un Mais à la fin, " si ce n'est pas cassé, ne pas Fixez-le ».
Par exemple, comparez le même écran sans et avec Editors.
Et quand je dis que le gin traite de la réductrice de la chaudière, ce n'est que si vous utilisez déjà
MVP peut également être excellent lorsque vous construisez des applications multi-facteurs: si les écrans peuvent être suffisamment similaires entre mobile, tablette et bureau, vous pouvez utiliser le même présentateur avec 3 vues différentes (et c'est là que DI brille !).
int sur un double , etc.); C'est une différence énorme par rapport à GWT-RPC, où vous aurez une erreur, même pour un changement très mineur et subtil de vos classes.