Séparation des niveaux présentation et business avec ressort

Question

Dans mon projet récemment terminé, je travaillais à faire fonctionner des transactions distribuées.

Nous avons implémenté cette solution en utilisant Arjuna Transaction Manager de JBoss et les limites des transactions déclaratives de Spring.

Notre séquence de requête ressemblait à:

browser -> secured servlet -> 'wafer-thin' SLSB -> spring TX-aware proxy -> request-handler POJO

Cela signifiait que nous avions un WAR pour servir notre servlet sécurisé et un EAR pour servir notre SLSB.

Notre SLSB disposait d'un bloc d'initialisation statique pour amorcer le contexte de notre application Spring.

Je n'aime pas la combinaison de technologies, mais j'aime bien la séparation des niveaux présentation et business, qui pourraient résider sur des emplacements physiques différents.

Je serais intéressé de savoir ce que les autres proposent de séparer les niveaux lors de l’utilisation de Spring?

Answer 1

Exiger un serveur d'applications EJB3 uniquement pour un SLSB qui est une façade ne semble pas en valoir la peine. Il n'y a aucune raison pour que vous ne puissiez pas simplement supprimer cela et laisser votre servlet fonctionner directement avec Spring. Vous pouvez ajouter ContextLoaderListener au fichier WAR pour charger votre ApplicationContext, puis WebApplicationContextUtils pour l'obtenir. Vous pouvez également utiliser SpringMVC, Struts ou d’autres technologies Web si vous devez faire plus que ce que le Servlet lui-même permettra.

Answer 2

Une approche assez typique consiste à définir un niveau Web, un niveau de service et un niveau DAO, et à associer une sémantique transactionnelle au niveau de service. Le niveau de service peut être constitué d'un ensemble de POJO avec des annotations @Transactional, par exemple. Le niveau Web peut être constitué de contrôleurs Spring Web MVC. Dans cette approche, le niveau Web adapte essentiellement le niveau de service à HTTP. Bonne séparation et pas besoin de SLSB ici.

Un domaine de débat concerne toutefois les objets de domaine, tels que Employee ou PurchaseOrder ou autre. Celles-ci s’étendent sur plusieurs niveaux d’application. Une chose qui semble se produire avec les annotations est que les objets de domaine reçoivent des annotations liées à des niveaux spécifiques. Vous pouvez donc avoir des annotations ORM ici, mais utiliser ensuite le même objet de domaine en tant que bean de sauvegarde de formulaire afin d’éviter les classes d’objets de domaine / formulaire parallèles. Certaines personnes s'opposent à cela en tant que violation de la séparation architecturale des préoccupations.