Quels sont les avantages et les inconvénients du motif J2EE Core Façade Core?

Question

Quels sont les avantages et les inconvénients du modèle J2EE Core Façade Core?

Quelles sont les hypothèses derrière cela?

Ces hypothèses sont-elles valables dans un environnement particulier?

Answer 1

Session Facade est un modèle fantastique. Il s’agit en fait d’une version spécifique du modèle Business Facade. L'idée est de lier les fonctionnalités de l'entreprise à des ensembles discrets - tels que TransferMoney (), Withdraw (), Deposit () ... afin que votre code d'interface utilisateur accède à des éléments en termes d'opérations commerciales au lieu d'un accès de données de bas niveau ou d'autres détails. qu'il ne devrait pas être concerné.

Plus précisément avec Session Facade - vous utilisez un EJB de session pour faire office de façade professionnelle - ce qui est bien, car vous pouvez tirer parti de tous les services J2EE (authentification / autorisation, transactions, etc.) ...

J'espère que ça aide ...

Answer 2

L’avantage principal du modèle Session Façade est qu’il est possible de diviser une application J2EE en groupes logiques par fonctionnalité d’entreprise. Une façade de session est appelée par un POJO à partir de l’UI (c’est-à-dire un délégué d’affaires) et contient des références aux objets d’accès aux données appropriés. Par exemple. Un PersonSessionFacade serait appelé par le PersonBusinessDelegate et pourrait ensuite appeler le PersonDAO. Les méthodes sur PersonSessionFacade suivront au minimum le modèle CRUD (Créer, Récupérer, Mettre à jour et Supprimer).

En règle générale, la plupart des façades de session sont implémentées sous la forme d’EJB de session sans état. Ou si vous utilisez Spring AOP pour les transactions, vous pouvez créer un service POJO qui peut être l’ensemble des points de jointure de votre gestionnaire de transactions.

Un autre avantage du modèle SessionFacade est que tout développeur J2EE possédant un minimum d’expérience vous comprendra immédiatement.

Inconvénients du modèle SessionFacade: il suppose une architecture d’entreprise spécifique, contrainte par les limites de la spécification J2EE 1.4 (voir les ouvrages de Rod Johnson pour ces critiques). L'inconvénient le plus préjudiciable est qu'il est plus compliqué que nécessaire. Dans la plupart des applications Web d'entreprise, vous aurez besoin d'un conteneur de servlets. La plupart des contraintes d'une application Web se situeront au niveau qui gère les requêtes HttpRequests ou l'accès à la base de données. Par conséquent, il ne semble pas utile de déployer le conteneur de servlets dans un espace de processus distinct du conteneur EJB. C'est à dire. les appels à distance aux EJB créent plus de douleur que de gain.

Answer 3

Rod Johnson affirme que la raison principale pour laquelle vous souhaitez utiliser une façade de session est si vous effectuez des transactions gérées par conteneur - ce qui n'est pas nécessaire avec des cadres plus modernes (comme Spring.)

Il dit que si vous avez une logique métier, mettez-la dans le POJO. (Ce sur quoi je suis d'accord - je pense que c'est une approche plus orientée objet - plutôt que de mettre en œuvre un EJB de session.) http://forum.springframework.org/showthread.php?t=18155

Heureux d’entendre des arguments contrastés.

Answer 4

Il semble que chaque fois que vous parlez de tout ce qui est lié à J2EE - il y a toujours toute une série d’hypothèses en coulisse - que les gens assument d’une manière ou d’une autre - ce qui conduit à la confusion. (J'aurais probablement pu clarifier la question aussi.)

En supposant que (a), nous souhaitons utiliser les transactions gérées par conteneur au sens strict via la spécification EJB, puis

Les façades de session sont une bonne idée, car elles suppriment les transactions de base de données de bas niveau pour pouvoir fournir une gestion des transactions d'application de niveau supérieur.

En supposant que (b) vous entendiez le concept architectural général de la façade de la session - puis

Décoder les services et les consommateurs et fournir une interface conviviale est une bonne idée. L'informatique a résolu de nombreux problèmes en "ajoutant une couche supplémentaire d'indirection".

Rod Johnson écrit que les SLSB avec interfaces distantes constituent une très bonne solution pour les applications distribuées construites sur RMI. Cependant, il s'agit d'une exigence de la minorité. L'expérience a montré que nous ne voulons pas utiliser une architecture distribuée à moins d'y être contraint par les exigences. Nous pouvons toujours, si nécessaire, desservir des clients distants en mettant en place une façade distante au-dessus d'un bon modèle d'objet colocalisé. (Johnson, R "Développement J2EE sans EJB" p119.)

En supposant (c) que vous considérez la spécification EJB (et en particulier le composant de façade de session) comme un fléau pour un paysage de bonne conception, alors:

Rod Johnson écrit "En général, il n'y a pas beaucoup de raisons pour lesquelles vous utiliseriez un SLSB local dans une application Spring, car Spring fournit une gestion déclarative des transactions plus performante que EJB, et CMT est normalement la principale motivation pour utiliser des SLSB locaux. Vous n’avez donc peut-être pas besoin de la couche EJB. " http://forum.springframework.org/showthread.php?t=18155

Dans un environnement où les performances et l’évolutivité du serveur Web constituent la préoccupation principale - et le coût est un problème - l’architecture de façade de session est moins attrayante - il peut être plus simple de parler directement à la base de données (bien qu’il hiérarchisation.)