Project:Omega.org

Par Apple Computer, Inc. © 2002 (Dernière mise à jour 3 Janvier 2002),

Traduit par Thierry, 20/03/2003.

Enterprise Objects est un système puissant qui rend l’usage de stockage persistant pour vos données presque transparent. Il évite la nécessité de travailler avec SQL ou tout autre langage de requête de bases de données en fournissant une API orientée objet que vous utilisez pour gérer vos données de la même manière que vous gérez de simples objets, sans tenir compte du type de support dans lequel résident vos données.

Cette couche d’abstraction vous permet de vous concentrer sur la logique métier de vos classes enterprise-object (les définitions de classes Java que EOModeler génére pour votre modèle de données) et vous évite de perdre votre temps à implémenter des douzaines de procédures de gestion de vos données. Elle vous permet aussi de tirer profit des avantages que le programmation orientée objet procure. EOModeler est une application qui vous permet de créer une modèle de données à partir d’un stock de données ou d’entités de ce stock, telles que les tables. Pour plus d’informations sur EOModeler, se reporter à Inside WebObjects: Using EOModeler.

Ce chapitre présente la théorie qui se cache derrière la technologie Enterprise Object. “Développer une Application Enterprise Objects”, présente la théorie à utiliser. Pour plus d’informations sur Enterprise Objects, se reporter à Inside WebObjects: Enterprise Objects.

Ce chapitre explique :

• les couches qui constituent une application Enterprise Objects,
• le rôle que le modèle joue dans une application Enterprise Objects.

Architecture Système

Enterprise Objects est une suite d’outils et de codes qui vous permettent de créer des applications reposant sur une base de données. Le tout est divisé en plusieurs couches affectées à la connexion à la base de données, à la conversion des résultats en instances enterprise-object et à la vérification que l’état des objets entreprise et celui de la base sont toujours synchronisés. WebObjects ajoute une autre couche au-dessus de Enterprise Objects, la couche accés. Cette couche, implémentée par les classes de com.webobjects.eoaccess, est utilisée pour manipuler les objets entreprise et afficher leurs données.

Les blocs de construction suivants constituent le modèle Enterprise Objects :

• Composants Web affiche et manipule les instances enterprise-object.
• Instances Enterprise-object sont les instances des classes EOGenericRecord ou Java que vous créez pour représenter les lignes de la base de données. EOGenericRecord (com.webobjects.eocontrol) apporte le comportement par défaut de propagation des changements dans le stock de données, mais ne permet pas l’ajout de logique personnalisée.
• Les contextes d’édition gèrent les diagrammes d’objets et gardent trace des changements qui doivent être transmis aux stocks de données.
• Le modèle de données (maintenu avec EOModeler) fournit une vue de haut niveau des entités de vos données. Il définit les liaisons entre les entités de données que votre application nécessite et les tables de votre base de données. Il définit aussi les relations entre les entités qui correspondent aux définitions des clé primaires et secondaires des tables de la base.Le modèle relie les colonnes de la base avec les attributs de chaque entité de votre modèle. Il désigne aussi la correspondance entre les types de données du stock de données et les types de données Java. Par exemple, vous pouvez déterminer qu’une colonne de type int doit être traduite en un objet de type Number (java.lang) lorsque les données sont lues à partir de la base.Le modèle spécifie aussi les informations requises pour se connecter à la base y compris les informations relatives au réseau et au mot de passe.
• La couche accès maintient une vue du stock de données dans des objets appelés dictionnaires. Lorsqu’une application lit des données dans une table de base de données, la couche adaptateur rapporte les lignes demandées et remplit les dictionnaires appropriés. A l’inverse, lorsqu’une application sauvegarde des données, la couche adaptateur écrit les informations, stockées dans ces dictionnaires, dans le stock de données.
• Le moteur du stock de données est externe à Enterprise Objects et fourni par une tierce partie.

La Figure 10-1 illustre l’approche que Enterprise Objects adopte lors des interactions avec une base de données.

Figure 10-1 L’approche Enterprise Objects

Les chapitres précédents vous ont appris à manipuler des objets avec des composants web. Les paragraphes qui suivent vous donnent quelques détails des traitements qui interviennent dans chaque couche Enterprise Objects lorsque des données sont lues dans un stock de données et y sont écrites.

Objets Entreprise

Un objet entreprise est d’abord et avant tout un objet Java. Il comporte des variables d’instance et des méthodes permettant de l’utiliser. Cependant, il a la caractéristique supplémentaire d’être lié à la structure d’une base de données par Enterprise Objects. Les objets entreprise diffèrent des autres objets en cela qu’ils sont la représentation de données stockées dans une base de données.

Chaque instance enterprise-object représente en général une ligne d’une base de données. Lorsque les propriétés (variables d’instance) d’un objet entreprise sont changées et que vous demandez à Enterprise Objects de sauvegarder ces changements, ils sont propagés au travers des différentes couches qui mènent à la base de données.

Une instance enterprise-object peut être une instance de la classe par défaut EOGenericRecord (com.webobjects.eocontrol) ou d’une classe Java personnalisée. Vous utiliserez un EOGenericRecord lorsque vous n’aurez besoin de rien de plus qu’une représentation basique des valeurs de la base. Vous définirez une classe enterprise-object personnalisée lorsque vous souhaiterez avoir plus de contrôle sur les propriétés et le comporteent des entités de données. Les classes enterprise-object personnalisées sont définies en tant que sous-classes de EOGenericRecord, elles héritent donc du comportement enterprise-object par défaut.

EOGenericRecords utilise un mécanisme de codage clé-valeur défini dans l’interface EOKeyValueCoding (com.webobjects.eocontrol) pour stocker leurs données. Chaque clé est identifiée en fonction de la colonne de la base qu’elle représente. Lorsqu’un objet entreprise est instancié à partir d’une ligne de la base de données, les valeurs de ses clés sont obtenues à partir des colonnes correspondantes de la ligne. Les éléments dynamiques WebObjects utilisent le codage clé-valeur pour obtenir et régler les attributs enterprise-object.

EOControl

La couche de contrôle est le domaine principal des instances enterprise-object. Elle apporte une couche isolée dédiée au maintien de l’état des objets entreprise. Les données y circulent et remontent vers la couche application (composants web dans des applications web) et peuvent être propagées vers le bas vers la base de données. La couche EOControl est responsable de :

• suivre les changements apportés aux objets entreprise,
• mettre à jour la base de données lorsque les changements sont sauvegardés,
• gérer les opérations de type “défaire” dans le diagramme objet,
• gérer l’unicité dans le diagramme objet.

L’unicité est utilisé par Enterprise Objects pour vérifier qu’une instance d’un objet entreprise n’est pas dupliquée dans la couche de contrôle. Ce mécanisme utilise la clé primaire d’une entité pour déterminer l’identité et l’unicité de chaque objet entreprise dans le diagramme objet. Il est important que les objets entreprise ne soient pas dupliqués dans le diagramme objet pour maintenir efficacement l’intégrité des données et l’utilisation de la mémoire. Par exemple, si deux livres ont le même auteur, la couche de contrôle vérifie qu’ils font tous les deux références au même objet Author en mémoire. Le maintien de l’unicité est une des responsabilités du diagramme objet.

Le Diagramme Objet

Un diagramme objet est une collection des instances enterprise-object actives d’un stock de données particuliers. Vous pouvez l’imaginer comme étant une photo instantannée de l’état courant de la base de données reflété dans des objets Java.

Un diagramme objet peut aussi représenter un état potentiel de la base de données. Si vos composants web effectuent des changements à des objets entreprises, ces changements sont stockés dans le diagramme objet jusqu’à ce qu’ils soient apportés à la base. Garder trace de ces changements est une des responsabilités de la classe EOEditingContext class (com.webobjects.eocontrol).

Le Contexte d’Edition

Chaque objet contexte d’édition gère un diagramme objet, gardant trace des changements apportés aux propriétés de chacun de ses objets entreprise. Il préserve aussi leurs valeurs d’origine de façon à ce que les changements puissent être défaits.

En général, un ensemble de changements reflétant les saisies utilisateur est accumulé dans le diagramme objet d’un contexte d’édition. A des instants données, les changements sont apportés à la base pour prise en compte, ou ils sont annulés, ramenant ainsi le diagramme objet à son état d’origine. Si les changements sont apportés à la base, le contexte d’édition notifie à la couche d’accès les changements apportés aux objets entreprise de façon à ce qu’elle puisse faire les changements nécessaires à la base.

Vous pouvez créer des contextes d’édition dans votre application. Cependant, par défaut, chaque session a un contexte qui lui est associé. Ce contexte d’édition par défaut, accessible par tous les composants, est en général suffisant.

EOAccess

La couche d’accès procure l’acès à la base de données au travers d’un protocole standardisé. Tous les morceaux de données qui traversent la couche d’accès sont sous la forme d’objets entreprise. Ce niveau d’abstraction rend le travail de la couche de contrôle beaucoup plus simple étant donné qu’elle peut compter sur le format des données.

La couche d’accès est divisée en deux parties : le niveau adaptateur et le niveau base de données.

Le Niveau Adaptateur

Le niveau adaptateur est l’endroit où Enterprise Objects traduit les données d’une base et les assemble en dictionnaires clé-valeur. Actuellement, le standard JDBC est utilisé pour les accès base de données, mais le niveau adaptateur permet l’accès à d’autres systèmes de base de données, telles que les bases de données ancestrales, simplement en ajoutant un adaptateur. Cela vous permet de ne pas vous sentir concerné par la spécificité d’une base de données à utiliser lorsque vous écrivez votre code.

Le Niveau Base de Données

Le niveau base de données gère les détails se rapportant à la base et dont vous n’avez pas à vous préoccuper. Les instances enterprise-object sont créées à partir de données brut de la base, et lorsque des données sont requises par la couche de contrôle, la couche base de données les rapportent à partir de la base. De la même manière, la couche base de données gèrent les mises à jour de la base lorsqu’un contexte d’édition est sauvegardé.

Textes originaux en anglais sur developer.apple.com : WebObjects Web Application - Introduction to Enterprise Objects

Thierry WebObjects Enterprise Objects, Mac OS X, WebObjects