EJB 3.1 @LocalBean vs pas d'annotation

Question

Je comprends la différence entre la vue locale, la vue distante et la vue sans interface. Mais je ne comprends pas quelle est la différence entre "no view" (pas d'annotation) et no-interface view. Et aussi pourquoi devrais-je annoter mon interface avec @Local ? Et si je n'annote pas du tout l'interface, y a-t-il une différence ?

Answer 1

Les règles sont (de mémoire) :

1. Bean a un @LocalBean annotation -> le haricot a une vue sans interface
2. Bean a un @Local annotation -> le haricot a une vue locale
3. Bean a un @Remote annotation -> le haricot a une vue distante
4. Le haricot n'a pas d'annotation de vue, mais implémente directement une interface qui a une annotation @Local -> le haricot a une vue locale.
5. Le haricot n'a pas d'annotation de vue, mais implémente directement une interface qui a une annotation @Remote -> le haricot a une vue distante.
6. Le haricot n'a pas d'annotation de vue, mais implémente directement une interface qui n'a pas d'annotation de vue -> le haricot a une vue locale.
7. Le haricot n'a pas d'annotations de vue et n'implémente aucune interface -> le haricot a une vue sans interface.

Donc, en utilisant @LocalBean et le fait de ne pas utiliser d'annotation du tout sont deux façons d'obtenir une vue sans interface. Si vous voulez simplement une vue sans interface, le plus simple est de ne pas annoter. À condition de ne pas implémenter d'interfaces.

C'est en partie la raison pour laquelle @LocalBean existe pour ajouter une vue sans interface à un haricot qui a également une vue d'interface. J'imagine que le scénario le plus important dans l'esprit des auteurs de la spécification était celui où vous avez un bean comme :

@Stateless
public class UserPreferences {
    public String getPreference(String preferenceName);
    public Map<String, String> getPreferences();
}

Dans le cas où vous voudriez exposer les deux méthodes localement, mais seulement la méthode à plus gros grain getPreferences() à distance. Pour ce faire, il suffit de déclarer une interface distante avec cette seule méthode, puis d'ajouter la fonction @LocalBean sur la classe du haricot. Sans cela, vous devriez écrire une interface locale inutile juste pour exposer les deux méthodes localement.

Ou, pour le voir d'une autre manière, la @LocalBean existe parce qu'il existe une vue sans interface, et l'option sans annotation existe comme un raccourci pratique.

Answer 2

• EJBs distants : on peut y accéder à partir de clients distants (clients fonctionnant sur une JVM différente, comme les clients Swing ou JavaFX qui fonctionnent sur la machine de l'utilisateur).
• EJBs locaux : on ne peut y accéder qu'à partir d'autres "composants" fonctionnant sur la même JVM, par exemple des frontaux Web, d'autres EJBs.
• Vue sans interface : identique à Local mais sans spécifier l'interface métier
• Pas d'annotation : un simple POJO mais pas un EJB

Les vues locales/non-interface sont plus efficaces que les EJB distants, car les références aux objets peuvent être transmises.

Answer 3

Je pense que la confusion que vous/nous ressentons est le résultat de l'histoire/de la compatibilité à rebours (pour ainsi dire). Je ne vois pas de différence (sauf que la spécification exige que les implémentations créent une interface si nous utilisons local-view).

La vue sans interface a le même comportement que la vue locale EJB 3.0, Par exemple, elle prend en charge des fonctionnalités telles que la sémantique d'appel pass-by-reference et la propagation des transactions et de la sécurité. et la propagation des transactions et de la sécurité. Cependant, une Toutefois, une vue sans interface ne nécessite pas d'interface distincte, c'est-à-dire que toutes les méthodes publiques de la classe de haricot sont utilisées. méthodes publiques de la classe du haricot sont automatiquement exposées à l'appelant. appelant. Par défaut, tout haricot de session qui possède une clause implements vide vide et ne définit pas d'autres vues client locales ou distantes, expose une vue client sans interface.

Blog d'Oracle avant la sortie d'EJB 3.1