Modèles de logique métier EJB3 & amp; Les pratiques

Question

Je suis en train de développer une application de traitement financier multiniveau en Java en utilisant EJB3 (Hibernate + Glassfish pour la couche d'applications et de services Web, Lift on Glassfish pour l'interface utilisateur Web) et la question me pose problème. d'où placer ma logique métier.

Lorsque ce projet a démarré, notre première idée était de mettre l'essentiel de notre logique métier dans les beans de session sans état. Cependant, avec le temps, nous avons trouvé que l'injection de dépendance fournie par le framework EJB était trop restrictive. Une grande partie de notre logique métier s'est donc retrouvée dans des POJO assemblés par Guice dans la méthode @PostConstruct des beans session stateless. . Ces progrès ont conduit à une fragmentation de notre logique métier entre les beans de session et les POJO, et j'essaie de trouver une approche pour corriger cela.

Initialement, nous avons essayé de faire en sorte que notre couche Web utilise les interfaces distantes des beans de session pour exécuter certaines fonctions accessibles à la fois à partir de l'interface utilisateur et de la couche de service Web, fournies par les beans de session sans état @ WebService-annotés. Cela s'est avéré être un cauchemar du point de vue de la persistance et des performances, car notre graphe d'entités peut devenir assez volumineux et le réattachement du graphe d'entités détachées au contexte de persistance s'est avéré très sujet aux erreurs. Notre solution consistait donc simplement à passer des objets. identifiants autour et recherche les entités de la base de données là où elles étaient nécessaires.

Ma question de base est la suivante: quels principes et quelles directives pouvez-vous suggérer pour décider si la logique métier doit être intégrée dans un bean de session ou dans un POJO? Quand est-il judicieux de passer des beans entité, à partir d'un graphe d'objet complexe?

Answer 1

J'ai eu du mal à cela lors de la création d'une application Web à l'aide de JPA, EJB3 et Wicket. Étant donné que frapper fort dans ma base de données avec des requêtes répétées était plus évolutif que de conserver beaucoup de grandes entités en mémoire, j'ai décidé de ne transmettre que leurs identifiants et jamais l'entité elle-même.

Wicket et son concept de modèles ont beaucoup à voir avec cette décision. LoadableDetachableModel nettoie les entités lorsqu'elles ne sont pas utilisées, tout en conservant l'identifiant. Une méthode load () est implémentée; elle sait comment obtenir l'entité lorsqu'elle est à nouveau utilisée, dans mon cas en appelant un bean de session sans état; et une méthode persist () appelle le bean sans état pour conserver les modifications. Cette classe de modèles est ce que je vous transmets en réalité. Wicket ne gère que la logique relative à la validation de l'affichage et des entrées, et je n'ai qu'à injecter l'ejb dans les classes du modèle. Peut-être que vous pourriez créer quelque chose de similaire dans votre application (je n'ai aucune idée de ce que l'ascenseur peut offrir ...).

Cela a bien fonctionné pour moi, mais je n'ai pas de logique métier particulièrement complexe et je peux isoler les modifications qui doivent être conservées dans de petites unités de logique et des pages simples.

Answer 2

Chaque fois que vous avez besoin de nombreux " systèmes " les services (injections, etc.) utilisent des fèves sans état. Sinon - POJOs. Les POJO sont beaucoup plus flexibles.

Cependant, des méthodes simples (accesseurs?) (par exemple, dans les services Web et les beans) peuvent simplement effectuer un travail simple et renvoyer les résultats.