Seam application Architecture

Question

J'ai besoin de mettre en place un système assez gros dans Seam. Je considère la manière de concevoir l'architecture. Si c'est bon d'utiliser des contrôleurs de page ou des contrôleurs d'application ou contrôleur frontal ou chacun d'entre eux. S'il est utile d'utiliser le bean backend, il n'est peut-être pas nécessaire de le faire. Si vous avez une suggestion ou un lien vers un article utile, je l'apprécierai.

Merci beaucoup!

Daniel Mikucki

Answer 1

Si vous avez besoin d'apprendre beaucoup de choses sur Seam pour un projet, je vous recommande de faire le livre Seam In Action, qui est le meilleur sur le sujet. Pour répondre à votre question, personnellement, je préfère utiliser le style pull-MVC dans Seam, où vous vous référez aux données dans vos modèles de vue que Seam prend soin d'initialiser, au besoin, en utilisant les méthodes @Factory. Cependant, il y a plus d'une façon de le faire dans Seam, donc il vaut la peine de lire d'abord les alternatives, d'où la recommandation de livre.

Vous pouvez également construire quelques applications Seam premier à jeter avant d'essayer de construire un « droit » :)

Answer 2

Daniel,

Il est conseillé d'utiliser un contrôleur frontal, la plupart des gens aren » t conscient de ce modèle de conception.

Il s'agit d'un modèle de conception vraiment bon à utiliser car il garantit que vous accédez à l'application via un seul point d'entrée. Vous pouvez surveiller tout ce qui va et vient facilement avec moins de configuration. Vous réduisez la quantité de duplication de code possible car il existe un seul point d'entrée. En plus d'avoir moins de code à maintenir, le code devrait être plus facile à suivre puisqu'il n'y a qu'une seule entrée. Vous pouvez alors facilement suivre le flux d'exécution de l'application.

Malheureusement pour Seam, il n'y a pas vraiment de motif de contrôleur frontal. Je n'ai pas passé autant de temps que je voudrais développer le mien, mais la sécurité et la vérification sont mes priorités.

En ce qui concerne les contrôleurs de page/application, dans Seam, vous avez plus de contextes ou d'étendues disponibles. Événement, Page, Conversation, Session, Application, pour en nommer la plupart.

Si vous développez un contrôleur ou dans Seam, une action de page, la plupart du temps, il sera basé sur les événements. C'est la portée la plus courte. Si vous avez des flux de pages, vous utiliserez alors des composants de portée conversationnelle.

Regardez les exemples dans le code source. Vous pouvez faire beaucoup de choses avec très peu de code, c'est incroyable, mais en même temps, il se passe beaucoup de choses qui peuvent prendre du temps.

La conception à plusieurs niveaux que suivent la plupart des endroits ne s'applique pas nécessairement ici. Pour la plupart de mes pages, je définis une requête que je vais utiliser en XML (requête d'entité), puis je l'injecte dans l'action de ma page et je l'appelle ici. Ainsi, au lieu d'avoir des classes controller, service, dao et entity, vous finissez avec simplement une action de page, les requêtes et les classes d'entités. Vous pouvez découper les couches de service et dao dans la plupart des cas.

Votre définition complète d'un service peut également changer. Pour moi, un service est un fournisseur de services tel que la notification, la sécurité (audit), la gestion des exceptions, etc. Tous ces services s'exécutent en arrière-plan et ne sont pas liés à une requête http particulière.

Walter

Answer 3

Daniel,

J'ai utilisé un contrôleur par page, un service et une dao par entité.

• logique de cas d'utilisation va dans le contrôleur
• logique métier spécifique entité va dans le service de l'entité.
• Actions qui couvrent plusieurs entités vous pouvez créer un service de façade - quelque chose qui se trouve entre les services de contrôleur et l'entité

Bien que ce qui précède est une bonne approche et pratique, idéalement:

• vous pourriez casser sortir tout code non MVC du contrôleur dans sa propre classe de service, c.-à-d. 1 classe de service par page
• Vous devez uniquement accéder à l'entité dao via le service d'entité.

Voilà comment le contrôle coulerait:

Idéalement: UI -> PageController.java -> PageService.java -> EntityService.java -> EntityDao.java

Pratiquement , vous pouvez réduire quelques couches: UI -> PageController.java -> EntityService.java

Ou pour les actions touchant plusieurs entités: UI -> PageController.java -> Facade.java -> Entity1Service.java, Entity2Service.java

PageController.java serait une Seam @component et dans votre ui vous pouvez vous référer comme: #{pageController} et extraire les données de la vue.

En architecture, la chose la plus importante est de savoir comment vous couchez les choses dans la pile, évitez les dépendances circulaires entre les couches. Par exemple, Entity Service ne doit pas référencer Controller et ainsi de suite.

L'autre chose importante est d'être cohérent sur la superposition dans toute l'application. Utilisez des générateurs de code si vous pouvez garder votre code cohérent à travers l'application, c'est vraiment payant pour les grands projets. Regardez dans Clickframes si vous êtes intéressé par la génération de code (Clickframes génère un code de démarrage pour les applications Seam avec support JPA/valdiation/sécurité complet que vous pouvez ensuite modifier). Voir ce Seam demo construire avec Clickframes si vous êtes intéressé.