Les modèles de conception permettent de meilleures applications J2EE

Depuis sa création, J2EE (Java 2 Platform, Enterprise Edition) a simplifié la construction d'applications d'entreprise en Java. Cependant, à mesure que J2EE devient plus largement adopté, les développeurs se rendent compte du besoin d'approches définies qui simplifient et normalisent à la fois la création d'applications. Vous pouvez commencer à atteindre cet objectif en standardisant la couche architecturale de votre application .

La couche architecturale encapsule généralement les complexités techniques d'une application indépendamment de la logique métier, fournissant ainsi un couplage lâche entre la fonctionnalité métier et l'infrastructure technique sous-jacente. Dans cet article, j'explique une méthode émergente pour créer l'architecture d'application pour les projets J2EE - une méthode qui utilise des modèles de conception pour fournir la standardisation et la simplicité requises par une bonne architecture.

Architecture d'application et J2EE

J2EE est une excellente technologie d'infrastructure. Il fournit une norme uniforme pour les tâches de niveau inférieur de la pile technologique, telles que la communication de base de données ou la distribution d'applications. Cependant, J2EE ne conduit pas les développeurs à créer des applications réussies. Les créateurs de J2EE, examinant la pile technologique, se sont demandé: "Comment pouvons-nous standardiser ces API?" Ils auraient dû consulter les développeurs d'applications et leur demander: "Comment puis-je donner aux développeurs les éléments de base dont ils ont besoin pour se concentrer sur leur application métier?"

Lors du démarrage d'un nouveau projet J2EE, certains membres de l'équipe demandent souvent: "Si J2EE est lui-même une architecture, pourquoi avons-nous besoin de plus?" De nombreux développeurs ont soutenu cette idée fausse au début de J2EE, mais les développeurs J2EE expérimentés comprennent que J2EE ne parvient pas à fournir l'architecture d'application nécessaire pour fournir systématiquement des applications de haute qualité. Ces développeurs utilisent souvent des modèles de conception pour combler cette lacune.

Modèles de conception

En programmation, les modèles de conception vous permettent de tirer parti de l'expérience collective de la communauté des développeurs en partageant des problèmes et des solutions qui profitent à tous. Un modèle de conception doit capturer la définition et le contexte d'un problème, une solution possible et les conséquences de la solution.

Aux fins de l'architecture d'application J2EE, les modèles de conception se répartissent en deux catégories: les modèles de développement logiciel généraux et les modèles qui identifient les défis J2EE spécifiques. Les modèles de conception spécifiques à J2EE identifient l'ensemble minimal de problèmes connus qu'une architecture d'application solide devrait résoudre. Le premier groupe, celui des modèles de développement logiciel non spécifiques à J2EE, s'avère tout aussi puissant - non pas pour identifier les problèmes, mais pour guider la construction de l'architecture.

Examinons chaque domaine plus en détail.

Modèles de conception J2EE

Les modèles de conception J2EE ont évolué au cours des dernières années au fur et à mesure que la communauté Java a acquis de l'expérience J2EE. Ces modèles de conception identifient les problèmes potentiels rencontrés lors de l'utilisation des différentes technologies spécifiées par J2EE et aident les développeurs à définir les exigences d'une architecture d'application. Le modèle de conception populaire Front Controller, par exemple, transforme le code de servlet non structuré en un contrôleur rappelant le développement raffiné de l'interface utilisateur graphique (GUI).

Les modèles de conception J2EE identifient les problèmes de domaine les plus susceptibles d'apparaître dans vos projets J2EE. En effet, si les problèmes étaient rares, les modèles de conception n'auraient pas évolué pour y répondre. Dans cet esprit, vous bénéficierez de la résolution de chaque problème de domaine dans votre architecture. Pour les résoudre tous, créez une liste de contrôle pour valider votre architecture pour l'exhaustivité. Ce processus contraste avec le processus des modèles de conception de développement logiciel dont je vais parler ensuite, car vous devez appliquer ces modèles uniquement lorsque et si cela est approprié.

Alors, où trouvez-vous les modèles de conception J2EE? Sun Microsystems propose deux livres contenant de nombreux modèles J2EE:

  • Le groupe J2EE BluePrint Designing Enterprise Applications avec la plate-forme Java 2 (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
  • Principaux modèles J2EE du groupe Sun Professional Services : meilleures pratiques et stratégies de conception, Deepak Alur, John Crupi et Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Voir Ressources pour les liens vers les deux livres.)

Au-delà des ressources de Sun, d'autres publications proposent des informations sur les modèles de conception J2EE, notamment divers magazines ou sites Web de l'industrie Java (tels que JavaWorld ), ainsi que de nombreux livres. (Voir Ressources pour les liens vers certains de ces sites, y compris « JavaWorld s design patterns topique la page Index.)

Modèles de conception de développement logiciel

Soyez également conscient des modèles de conception de développement logiciel, divisés en modèles de conception généraux orientés objet (OO) et en modèles de conception spécifiques à Java. Le modèle Factory, par exemple, représente un modèle de conception OO puissant pour encapsuler la création d'objets afin de permettre la réutilisation et de répondre aux exigences changeantes d'un système. Pour leur part, les modèles de conception en langage Java tiennent compte des spécificités du langage Java. Certains sont uniques à Java et sont généralement informels (par exemple, les exceptions et les primitives), tandis que d'autres sont des modèles OO affinés pour s'appliquer à Java. Le célèbre livre Gang of Four, Design Patterns par Eric Gamma et al., Détaille de nombreux modèles généraux de développement de logiciels utiles à tous les programmeurs.

N'écartez pas ces modèles simplement parce qu'ils ne sont pas spécifiques à J2EE. Au contraire, ces modèles peuvent s'avérer tout aussi puissants, sinon plus, que les modèles de conception J2EE, car:

  • Alors que les modèles de conception J2EE sont nouveaux et en évolution (parce que J2EE est nouveau et en évolution), les autres modèles bénéficient de l'âge, car l'industrie a eu plus de temps pour les revoir et les affiner.
  • Ils servent souvent de base aux modèles de conception J2EE.
  • Ils construisent la base sur laquelle les solutions spécifiques à J2EE sont mises en œuvre. Construire correctement cette fondation affecte largement la robustesse et l'extensibilité de toute l'architecture. Si elle n'est pas construite correctement, la fondation minimiserait l'utilité de l'architecture quel que soit le nombre de problèmes J2EE qu'elle résout.

Ne faites pas de liste de contrôle couvrant les modèles de développement logiciel requis par votre architecture, comme vous le feriez avec les modèles J2EE. Au lieu de cela, utilisez de tels modèles, le cas échéant, en fonction des défis spécifiques de votre projet. De nombreux développeurs pensent à tort que leurs produits s'amélioreront s'ils utilisent plus de modèles - ou s'ils les utilisent tous! Ce n’est cependant pas le cas. Faites preuve de discrétion et de finesse lorsque vous décidez des motifs à utiliser et comment les utiliser ensemble.

Modèles de conception: où est le code?

Gardez à l'esprit que les modèles de conception ne sont pas fournis avec l'implémentation exacte ou le code source que vous utiliserez. Les offres de modèles de conception vont des descriptions textuelles clairsemées à une documentation riche en passant par un exemple de code. Le défi consiste à appliquer les idées puissantes des modèles. Ces idées doivent être appliquées à l'environnement dans lequel elles seront utilisées; l'environnement définit l'implémentation correcte.

Par analogie, considérons un modèle de conception pour la construction des fondations d'une maison. Le modèle de conception identifie le problème, le contexte et la solution possible pour construire la fondation - des informations extrêmement précieuses pour le travailleur de la construction sur le terrain. Le travailleur doit encore, cependant, construire les fondations. Ce travailleur de la construction ne gagnerait-il pas plus à recevoir les fondations (comme le développeur de logiciels reçoit la mise en œuvre)? Peut-être que cette fondation ne serait qu'une dalle de béton sur laquelle la maison pourrait être construite. Le problème: la fondation doit s'intégrer à la maison elle-même et au terrain où la maison résidera. Comment une telle fondation préfabriquée peut-elle accueillir tous les plans d'étage possibles (rectangle, carré et autres formes étranges) et tous les paysages possibles (au sommet d'une colline,au milieu d'une forêt, et ainsi de suite)?

De retour dans le monde du logiciel, la faisabilité de l'utilisation de modèles de conception prédéfinis dépend de deux facteurs:

  • L'implémentation, et non les modèles de conception individuels, représente une solution. La solution pourrait incorporer plusieurs modèles de conception et, ce faisant, saurait comment les modèles de conception individuels jouent ensemble.
  • La solution doit être adaptable, ce qui répond à la dernière question de l'analogie de la fondation préconstruite: la fondation doit pouvoir s'adapter au terrain et aux plans d'étage. Comme vous pouvez l'imaginer, il faudrait un artisan extrêmement qualifié pour construire la fondation adaptable par opposition à la fondation standard.

Modèles de conception courants

Le tableau ci-dessous répertorie certains modèles de conception courants provenant à la fois de sources J2EE et de modèles OO plus larges.

Modèles de conception courants
Modèles de conception J2EE Modèles de développement logiciel
Façade de session Singleton
Assembleur d'objets de valeur Pont
Modèle de localisateur de service Prototype
Délégué commercial Usine abstraite
Entité composite Poids mouche
Gestionnaire de liste de valeurs Médiateur
Localisateur de service Stratégie
Entité composite Décorateur
Objet de valeur Etat
Service au travailleur Itérateur
Objet d'accès aux données Chaîne de responsabilité
Filtre d'interception Model View Controller II
Voir Helper Mémento
Vue composite Constructeur
Vue du répartiteur Méthode d'usine

Examinons deux exemples de modèles de conception J2EE: les modèles de façade de session et d'objet de valeur. Les deux démontrent comment les modèles de conception J2EE se concentrent sur des problèmes particuliers à l'environnement J2EE, par opposition aux modèles de conception de développement logiciel qui s'appliquent généralement à tout effort de développement d'applications.

Exemple: le modèle J2EE de la façade de session

Le modèle Session Facade a évolué à partir d'expériences avec les Enterprise JavaBeans (EJB). Les systèmes basés sur les EJB d'entité nouvellement introduits (qui communiquent avec une base de données) ralentissaient jusqu'à l'exploration. Les tests de performance ont révélé des problèmes résultant de plusieurs appels réseau effectués lors de la communication avec les EJB d'entité, ce qui a ajouté une surcharge pour l'établissement de la connexion réseau, la sérialisation des données pour l'envoi et la réception, et d'autres effets.

En réponse, le modèle Session Facade a amélioré les performances en centralisant ces multiples accès réseau en un seul appel. Session Facade utilise un EJB de session sans état pour assurer la médiation entre l'appel client et l'interaction EJB d'entité requise. D'autres modèles existent pour améliorer les performances d'accès aux bases de données, y compris les modèles Fast Lane Reader et Data Access Object.

Exemple: modèle J2EE d'objet de valeur

Le modèle Value Object J2EE vise également à améliorer les performances des systèmes qui utilisent des EJB sur le réseau. Ces appels réseau induisant une surcharge de l'exemple précédent récupèrent des champs de données individuels. Par exemple, vous pouvez avoir un PersonEJB entité avec des méthodes telles que getFirstName(), getMiddleName()et getLastName(). Avec le modèle de conception Objet de valeur, vous pouvez réduire ces appels réseau multiples en un seul appel avec une méthode sur l'EJB d'entité, telle que getPersonValueObject(), qui renvoie les données en une seule fois. Cet objet de valeur contient les données que l'EJB d'entité représente et peut être accédé selon les besoins sans entraîner de surcharge d'appel réseau.

Exemple: le modèle Flyweight OO

Pour un exemple de modèle de conception OO largement applicable, considérez le modèle Flyweight, qui améliore les performances de l'application grâce à la réutilisation des objets. Le logiciel OO produit une surcharge (cycles de processeur inutiles, garbage collection et allocation de mémoire) lorsqu'il crée et détruit un objet. Si le système pouvait réutiliser ces objets, vous pourriez éviter cette surcharge. Cependant, les objets ne sont souvent pas réutilisables, car ils contiennent des informations (appelées état ) spécifiques à l'utilisateur actuel de l'objet. Le modèle Flyweight fournit des approches pour déplacer cet état ailleurs afin que le reste de l'objet puisse être réutilisé.

Mettez-les tous ensemble: exemple de persistance

Maintenant que vous connaissez les bases, vous pouvez commencer à appliquer des modèles de conception dans vos pratiques de développement. Mais comment utilisez-vous réellement les modèles? Commencez par identifier un domaine ou un problème technique nécessitant une solution. La persistance - résolution de la non-correspondance séculaire objet-base de données relationnelle - représente un bon exemple pour la plupart des applications d'entreprise. Voyons les étapes nécessaires pour concevoir et créer la couche de persistance d'une architecture d'application.

En suivant l'architecture OO traditionnelle et l'approche de conception, créez des cas d'utilisation décrivant vos besoins de persistance. Les cas d'utilisation possibles incluent:

  1. La persistance des objets doit être transparente du point de vue des développeurs.
  2. Les mécanismes de persistance (EJB d'entité, objets d'accès aux données, etc.) doivent être configurables au niveau architectural.
  3. Notre architecture doit utiliser les technologies J2EE mais encapsuler les dépendances J2EE. Nous devrions être en mesure de changer de fournisseur de serveurs d'applications J2EE, de versions J2EE ou de remplacer complètement J2EE sans nécessiter une révision complète de l'application.
  4. La couche de persistance résultante doit être réutilisable dans tous les projets. Cela devrait faire partie de notre architecture d'application continue.

Une fois que vous avez identifié le problème, vous pouvez décider quels modèles s'appliquent. N'oubliez pas que pour les modèles J2EE, vous devez déterminer les modèles qui s'appliquent dans la zone à problème et les résoudre. Pour la persistance, les modèles de conception J2EE pertinents sont (voir les livres de modèles de conception J2EE de Sun dans les ressources):

  • Objet de valeur
  • Lecteur de voie rapide
  • Objet d'accès aux données
  • Façade de session
  • Entité composite
  • Gestionnaire de liste de valeurs

Étant donné que vous utiliserez des EJB, incluez les modèles Business Delegate et Service Locator pour gérer l'accès aux EJB.

De plus, la résolution des deuxième et troisième cas d'utilisation nécessite des modèles de conception de développement logiciel traditionnels. Comment encapsulez-vous les dépendances et disposez-vous de mécanismes de persistance configurables? Certains modèles de développement logiciel applicables incluent:

  • Usine
  • Médiateur
  • Stratégie