simple mais bon modèle pour EJB

Question

Que proposeriez-vous comme un bon et le modèle pratique mais simple pour une solution avec:

• HTML + JSP (en vue/présentation)
• servlets (contrôleur, demande , séance de manipulation)
• EJB (persistance, BusinessLogic)
• MySQL DB

Et est-il nécessaire d'utiliser une couche propre de DAO pour par sistence? J'utilise JPA pour persister des objets dans ma base de données. Dois-je retirer la logique métier de mon EJB? Toutes les sources en ligne me disent des choses différentes et me confond ...

Answer 1

Je mettrais définitivement la logique métier dans les beans de session sans état. Les beans de session sans état sont agréables car ils capturent bien les limites de la transaction. Et il dissocie la couche Vue de la couche de persistance.

Veillez à ce que les méthodes de la SSB correspondent aux objectifs de petite entreprise que l'utilisateur souhaite atteindre. Un autre point est que vous devez vous assurer que les données que vous renvoyez ont toutes les données dans l'arborescence d'objets et que vous ne comptez pas sur le chargement paresseux pour obtenir le reste, car cela provoque toutes sortes de problèmes. Restez le plus loin possible des Stateful Session Beans: ce sont de mauvaises nouvelles et un concept brisé dans le contexte d'une application Web. Pour les choses à long terme, pensez à utiliser des beans gérés par message que vous déclenchez en envoyant un message JMS. Il s'agit d'une manière agréable de faire du traitement en arrière-plan, ce qui libère la logique métier plus rapidement, raccourcit les transactions et restitue le contrôle à l'utilisateur final plus rapidement.

Answer 2

Que proposeriez-vous comme un bon et le modèle pratique mais simple pour une solution avec JSP/Servlets + EJB + MySQL

Utilisez le framework MVC de votre choix, Stateless Session Beans pour la logique métier et la gestion des transactions (préférez les interfaces locales si vous n'avez pas besoin d'accès distant), Entités pour la persistance. Injectez vos EJB dans la mesure du possible (si vous utilisez Java EE 6, cela signifie n'importe où et vous pouvez également ignorer l'interface).

Et est-il nécessaire d'utiliser une propre couche de DAO pour la persistance? J'utilise JPA pour persister des objets dans ma base de données.

Certains pourraient dire oui, je dis non dans la plupart des cas. Le EntityManager implémente déjà le modèle Domain Store, il n'est pas nécessaire de le protéger derrière un DAO pour besoins simples.

Vous pouvez lire les ressources suivantes pour plus d'opinions sur ce point:

• Has JPA Killed the DAO?,
• JPA/EJB3 killed the DAO,
• et plus récemment DAOs Aren't Dead - But They Either Collapsed Or Disappeared

Dois-je retirer logique métier de mon EJB?

Je ne le ferais pas. Mettez votre logique métier dans vos beans Session (sans état). Les EJB3 sont des POJO, ils sont facilement testables, il n'est pas nécessaire de déléguer la logique métier à une autre couche.

Answer 3

Anno 2012 Je ne recommanderais pas d'utiliser Servlets et JSP comme couche de présentation. Cela faisait fureur en 2002, mais c'était il y a une décennie.

Aujourd'hui, Java EE a une excellente structure MVC appelée JSF. Il vaut mieux utiliser cela à la place. Vous voulez probablement récupérer des Widgets de la bibliothèque de composants PrimeFaces, car tous les Widgets standard sont un peu basiques. Une bibliothèque utilitaire comme OmniFaces est un excellent ajout.

En ce qui concerne les DAO; n'allez pas aussi loin que d'utiliser directement le gestionnaire d'entité dans les beans de support (JSF), mais si vous utilisez déjà des classes de service (limites transactionnelles) pour votre logique métier, l'utilisation d'un DAO peut également être excessive. Il existe encore quelques petits avantages d'un DAO, comme un dao.findByName (...) semble un peu plus clair que le chargement d'une requête nommée, la définition d'un paramètre, et obtenir un (unique) résultat, mais le coût est que vous devez gérer un DAO séparé pour chaque entité, probablement en plus de certains services.