Les applications Eclipse Scout reposent sur un registre de service. Ces services sont définis par une interface, placé dans le plug-in shared accessible côté client comme côté serveur. L’appel à l’un de ces services s’effectue toujours de la même manière:
IQuestionsListProcessService service = SERVICES.getService(IQuestionsListProcessService.class);
Côté client, deux cas se présentent:
* une implémentation est disponible côté client. Dans ce cas elle est retournée par cet appel.
* l’implémentation se trouve côté serveur. Dans ce cas, un proxy est retourné, et l’appel à la fonction est transmis au serveur par Eclipse Scout.
Ce registre de services gère plusieurs implémentations pour une même interface. Il est possible de définir une priorité pour donner un ordre entre les implémentations.
D’où mon idée de septembre dernier de proposer pour chaque service une implémentation se passant de la base de données. Dans ce cas il n’y a plus de persistance des informations, mais dans le cas de démonstration ou de tests cela peut être suffisant.
Je l’ai mis en oeuvre pour mon application MCQS.
Depuis ce commit, je dispose maintenant d’un fragment org.eclipselabs.mcqs.server.nodb.frament qui propose une implémentation des services avec une priorité plus haute. Lorsque le fragment est chargé avec le serveur (ce qui est le cas avec le produit server/products/nodb), ce sont ses implémentations qui ont la priorité.
Ce n’est pas encore tout à fait parfait, car pour faire les choses proprement il ne faudrait pas avoir de dépendance à la base de données dans le plug-in serveur principal, mais dans un deuxième fragment (et utiliser l’un ou l’autre).
Mon fragment NoDB est rudimentaire. Il ne garde rien en mémoire, ce qui devrait être possible.
Dans tous les cas, c’est un bon cas d’exemple de l’annotation @Priority que l’on peut ajouter sur chacun des services.
