Séparation de la présentation et des niveaux d'affaires avec le printemps

Question

Dans mon projet qui venait d'être terminé, je travaillais à faire fonctionner les transactions distribuées.

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

Notre séquence de demande ressemblait à:

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

Ce que cela signifie est que nous avions une guerre pour servir notre servlet sécurisé et une oreille pour servir notre SLSB.

Notre SLSB avait un bloc initialiseur statique pour amorcer notre contexte d'application Spring. Je n'aime pas la combinaison des technologies, mais j'aime la séparation des niveaux de présentation et d'affaires, qui pourraient résider à différents endroits physiques.

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

Answer 1

Exiger un serveur d'application EJB3 juste pour une SLSB qui est une façade ne semble pas que cela en vaille la peine. Il n'y a aucune raison que vous ne puissiez pas simplement supprimer cela et que votre servlet travaille directement avec Spring. Vous pouvez ajouter le ContextLoaderListener à WAR pour charger votre ApplicationContext, puis WebApplicationContextUtils pour y accéder. Vous pouvez également utiliser SpringMVC, Struts ou d'autres technologies Web si vous avez besoin de faire plus que ce que le servlet seul le permet.

Answer 2

Une approche assez typique consiste à définir un niveau Web, un niveau de service et un niveau DAO, et à joindre une sémantique transactionnelle au niveau de service. Le niveau de service peut être un groupe de POJO avec des annotations @Transactional, par exemple. Le niveau Web peut être des 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. Cependant, un domaine de discussion concerne les objets de domaine, tels que Employee ou PurchaseOrder ou autre. Ces étendues d'application étendues et une chose qui semble se produire avec les annotations est que les objets de domaine obtiennent des annotations liées à des niveaux spécifiques. Vous pouvez donc avoir des annotations ORM ici, mais utiliser le même objet de domaine en tant que bean de mise en forme afin d'éviter les classes d'objets de type domaine/parallèle. Certaines personnes s'opposent à cela en violant la séparation architecturale des préoccupations.