Discussion :

[professeur shadoko]

Bonjour à tous,
je reconnais que jusqu'à présent j'ai négligé J2EE... je considerais ça comme un vague cousin de province un peu *$%*** et porté sur les zigouigouis
Bon il faut que je jette mes préjugés à la poubelle et que j'essaye d'apprendre J2EE nouvelle mouture car il parait que c'est mieux.

Donc je parcours (un peu vite je reconnais) quelques documents explicatifs et j'ai des problèmes de compréhension.
Mon problème number one concerne la notion d'entité.
Je comprends ceci:
- les codes "entité" servent à l'intermédiation entre l'application et la persistence. On a là des notions hybrides: pas tout à fait objet mais plus que structure de données (puisqu'il y peut y avoir du code chargé de renforcer la cohérence des données, etc..)
- Il me semble que ces codes sont définis pas les développeurs (d'application ou de composants) puisqu'ils sont utilisés par l'appli.
- Au déploiement il faut définir les correspondances entre l'entité et la Base de données (donc c'est le boulot de la personne qui déploie)
- là où je ne comprends plus rien c'est de voir de la config par annotation sur le code d'entité... Comment est-ce possible?
Je veux dire ceci: une configuration par code est plus souple qu'une configuration statique et que du code soit écrit au déploiement me semble une bonne chose.... mais je ne peux pas imaginer que le "déployeur" doive reprendre et modifier les sources définies par les programmeurs applicatifs.

Donc j'ai pas bien compris...
Merci pour vos lumières

[xv-mnt]

Les entitées servent bien à effectuer le mapping entre l'appli et la DB.
Cependant, c'est bien le développeur qui réalise ce mapping. En simplifiant :
- telle classe ce mappe sur telle table
- tel attribut se mappe sur telle colonne de la table.
Je passe outre les considérations d'héritage et autres stratégies de mapping, et les liens. C'est la raison pour laquelle les annotations se trouvent dans les classes entitées.

Le déployeur doit juste vérifier que l'appli déployée se connecte à la bonne DB.
Pour cela, on utilise les noms JNDI : le développeur utilise le nom JNDI d'une DataSource pour se connecter à une DB, et c'est le déployeur qui configure le serveur d'application pour que ce nom JNDI corresponde à la bonne DB.
Par exemple, dans le cadre des EJB3, on peut trouver dans le fichier persistence.xml le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
	version="1.0">
	
	<persistence-unit name="myApp" transaction-type="JTA">
		<jta-data-source>jdbc/jtaDS</jta-data-source>

Le nom JNDI est jdbc/jtaDS.
Il suffit que dans le serveur d'application ce nom JNDI souit créé et décrive une DataSource pointant sur la DB souhaitée.

[professeur shadoko]

Cependant, c'est bien le développeur qui réalise ce mapping. En simplifiant :
- telle classe ce mappe sur telle table
- tel attribut se mappe sur telle colonne de la table.

ben c'est justement la substance de ma question: comment est-ce possible?
dans de très nombreux cas le développeur ne va pas connaître ces informations! (et en plus la séparation des rôles ne devrait pas permettre ça -au moins en théorie ).

[xv-mnt]

Il serait étonnant qu'un développeur qui développe une appli qui effectue de la persistance ne connaisse pas le modèle de données en base !
Qu'un développeur qui ne fasse que de l'IHM ne le connaisse pas je veux bien, mais le développeur qui s'occupe de la persistance DOIT connaître le modèle de donnée. Comment testera-t-il sinon ?
En imaginant qu'il n'y ait pas de mapping O/R et que tout soit fait à la mimine en JDBC pur, les requêtes CRUD doivent ête écrites => connaissance du modèle de données en base, non ?

Ou bien je ne comprends pas ton processus de développement...

[professeur shadoko]

Il serait étonnant qu'un développeur qui développe une appli qui effectue de la persistance ne connaisse pas le modèle de données en base !

en info classique oui, mais justement on nous "vend" une architecture par composants.
imagine un devt. applicatif qui developpe un truc simple de vente de "produits" en ligne ... ensuite on l'adapte à l'existant d'une B.D.D.
dans laquelle ces produits se retrouvent dans des tables distinctes avec des gestion du stock différentes selon les implantations , etc.
il me semble que le propre d'une grande quantité de bases de données n'est pas de servir une application particulière mais de servir de bases pour les "données de l'entreprise" et que ces données sont susceptibles d'être attaquées par des applications fort différentes.
Je sais bien que ce n'est pas le cas de bien des applications J2EE et que la schéma de la base est alors conçu spécifiquement pour les besoins de l'appli. mais, à mon avis, ça ne justifie plus de "vendre" une architecture par composants si les rôles de déploiement et de développement ne peuvent pas être disjoints.
ergo: on fait comment pour appliquer la théorie annoncée de séparation des rôles?
ou bien on dit que c'est le "responsable de déploiement" qui annote les codes des entités (et ça me semble bizarrissime) ou bien on dit que c'est le développeur applicatif (et ça me semble totalement ad hoc).
Bon en torturant à mort la technologie on doit pouvoir lui faire avouer n'importe quoi mais je suis curieux de savoir quelles sont les tortures les plus courantes

[xv-mnt]

J'ai du mal à saisir ton terme de composants. D'après tes propos et en suivant ton exemple, il semble que tu parles de composants génériques, ici des produits que tu adaptes suivant les besoins des différents clients et leurs propres bases de données. Ceci est très difficile à réaliser quelle que soit la techno utilisée, puisqu'on essaie de modéliser un type d'application qui se configure au gré des clients.

J2EE, pour moi, se place à un niveau plus bas, et il n'a jamais été vendu comme une solution de métamodèles métier. Ce qu'il réalise en revanche, ce sont de gérer des problématiques transverses, telles que la sécurité et les transactions.

Pour en revenir au rôles développeur/deployeur, c'est bien de la responsabilité du développeur de mapper son appli sur la DB en toute connaissance du modèle de données, et au déployeur de configurer le serveur d'application pour que l'EAR livré par le développeur puisse fonctionner correctement dans les différents environnements de test, preprod et prod.

Mais rien n'empecherait de réaliser en J2EE une application ultragénérique pour essayer de réaliser ton use case. Je t'avoue ce doit être plutôt trapu à faire quelle que soit la techno utilisée !

[professeur shadoko]

bon je vais essayer d'expliquer les choses différemment.
une question rigolote: pourquoi utiliser une bases de données relationelles pour faire de la persistence d'une application?

à mon (humble) avis les bonnes réponses doivent osciller entre:
- parceque c'est tellement un standard qu'on a oublié à quoi sert une BDD relationnelle. C'est vrai je me sers de la base que pour les besoins exclusifs de mon application et mes requêtes SQL n'impliquent pas des acrobaties relationelles. j'ai tellement l'habitude que je mets trois fois moins de temps à développer qu'en utilisant un système de persistence navigationnel (je sais que dans ce cas j'irais deux fois plus vite en performances mais qui s'en préoccupe? )
- parceque je partage des données avec les autres applications d'entreprise.

Dans le second cas la société X définit les tables (et l'application J2EE de marque X les utilisent), maintenant la société fait appel à l'application de marque Y qui sait parfaitement que ses clients ont dans leur système quelque chose qui décrit par exemple un employé (ou un client, ou ce que tu veux comme type de donnée qu'on peut raisonnablement trouver) Y ne connait bien évidement pas les tables et les noms des colonnes de l'entreprise (même si elle sait que les données sont là).
d'où mapping tables/entités fait au déploiement.
on peut rajouter des d'autres raisons (tuning) pour modifier au déploiement des requêtes, etc.
Donc je reviens à ce que je suppose être une base de J2EE: mapping objet/relationnel est d'abord un problème de déploiement (sinon pas la peine de se casser: on fait en COBOL comme d'ab. )

[professeur shadoko]

J il semble que tu parles de composants génériques, ici des produits que tu adaptes suivant les besoins des différents clients et leurs propres bases de données. Ceci est très difficile à réaliser quelle que soit la techno utilisée, puisqu'on essaie de modéliser un type d'application qui se configure au gré des clients.

En Java "pur" c'est tellement simple à faire! tu vends des produits abstraits et tu appliques le programme à des tas de truc concrets (on programme "objet" non?)

[bigtris]

xv-mnt a écrit: Pour en revenir au rôles développeur/deployeur, c'est bien de la responsabilité du développeur de mapper son appli sur la DB en toute connaissance du modèle de données

J2EE 1.4:
La question ne se pose pas vraiement pour les BMP (Bean Managed Persistence) parce que la persistence est totalement à la charge du developpeur. Par contre pour les CMP (Container Managed Persistence) le developpeur peut ne pas avoir connaissance de la DB. En effet, il déclare ses bean persistants avec champs, les relations, les requetes en langage EJB-QL et le tout bien documenté dans le fichier standard ejb-jar.xml. De son coté, le déployeur fait le boulot d'intégration en faisant un mapping basé sur le contenu du ejb-jar.xml vers le schema de la base dans un format généralement spécifique au serveur d'application.
Bien, ça c'est la théorie. Dans la pratique, le développeur joue aussi le role de deployeur ne serait ce que pour tester ses composants avant livraison.

JEE 5:
Les services de persistence sont fournis par la JPA (Java persistence API) qui propose un mapping par annotation dans le code source. Donc, le mapping reste en partie à charge du developpeur. Les CMP existent toujours mais pour des raisons de backward compatibility .

[xv-mnt]

En Java "pur" c'est tellement simple à faire! tu vends des produits abstraits et tu appliques le programme à des tas de truc concrets (on programme "objet" non?)

Puisqu'on est en "objet", qui alors va écrire la partie concrète ? Le vendeur de la partie abstraite ou l'acheteur qui doit écrire la partie concrète, et donc qui dopit lui même remapper. De plus, est-on sur qu'il suffit de remapper pour que çà marche ?
Pour le client 1, la référence produit peut être un nombre, et pour le client 2 une String. Un simple remapping au déploiement foirerait, non ?

[professeur shadoko]

Puisqu'on est en "objet", qui alors va écrire la partie concrète ? Le vendeur de la partie abstraite ou l'acheteur qui doit écrire la partie concrète, et donc qui dopit lui même remapper. De plus, est-on sur qu'il suffit de remapper pour que çà marche ?
Pour le client 1, la référence produit peut être un nombre, et pour le client 2 une String. Un simple remapping au déploiement foirerait, non ?

rien de tout ça.
Un fichier properties contient les requêtes concrètes et des infos pour faire le mapping: c'est (assez) simple.
l'exemple de la référence n'est pas bien choisi pour aborder les problèmes de type parceque la ref ne faisant l'objet d'aucune opération métier tu la sors en "String" et ça marche toujours. Dans une grande majorité des cas on s'en sort sans code Java.
MAIS ça n'a pas certains avantages d'un système de persistence avec évaluation paresseuse des valeurs, cache etc.... C'est pour ça que je veux apprendre J2EE

[professeur shadoko]

J
JEE 5:
Les services de persistence sont fournis par la JPA (Java persistence API) qui propose un mapping par annotation dans le code source. Donc, le mapping reste en partie à charge du developpeur. Les CMP existent toujours mais pour des raisons de backward compatibility .

merci ....
mais c'est là que je ne comprends pas pourquoi on a choisi cette option... ça me semble contradictoire avec certains objectifs de J2EE.
j'ai bien dit "me semble" car les gars ont dû bien réfléchir à leur truc et j'aimerais qu'on m'explique.
j'ai bien sûr imaginé des trucs compliqués à base d'Interceptor mais je pense pas qu'il faille torturer la technologie à ce point.

[bigtris]

merci ....
mais c'est là que je ne comprends pas pourquoi on a choisi cette option... ça me semble contradictoire avec certains objectifs de J2EE.
j'ai bien dit "me semble" car les gars ont dû bien réfléchir à leur truc et j'aimerais qu'on m'explique.
j'ai bien sûr imaginé des trucs compliqués à base d'Interceptor mais je pense pas qu'il faille torturer la technologie à ce point.

Juste un petit détail: il est aussi possible de définir un mapping à l'exterieur du sources dans fichier XML mais les évangelistes en font très peu la promo. Personnellement, pour des entités qui servent aussi d'objets de transfer, je préfère le mapping XML pour concerver l'indépendance de code par rapport à la JPA.

Peux-tu préciser les objectifs auquels tu penses ?

Dans tous les cas le principe de mapping par annotation étais déjà utilisé dans la pratique avant Java/JEE 5 par des outils tel que Xdoclet.

[professeur shadoko]

Peux-tu préciser les objectifs auquels tu penses ?

pas vraiment puisque , pour le moment, ça reste une question générale sur les principes.
a priori j'aime pas l'idée de mélanger la définition de l'entité et son mapping et je cherche à savoir si je me fais des idées sans importance pratique ou si d'autres se sont fait la même remarque en y apportant des solutions élégantes et de bon goût.

[professeur shadoko]

après consultation des oracles voici ce qui a l'air de constituer une réponse:
bien entendu la séparation développeur/déployeur existe toujours
MAIS

- en annotant ses entités le développeur déclare un déploiement de référence c'est à dire quequechose qui lui permet:
* de tester son application
* de faire un déploiement standard pour les applications pour lesquelles la base est dédiée.

- le déployeur lui a toujours sa configuration de déploiement XML qui prend le dessus sur le déploiement de référence (c.a.d. les modifications impliquées par la config XML sont prioritaires par rapport au déploiement de référence)

Commentaires:
- les principes de base sont toujours là
- je suis étonné qu'ils ne soient pas mieux rendus publics et expliqués
- je reste persuadé que les config "statiques" en XML son insuffisantes (les problèmes de performance de persistence sont trop aigus pour qu'on ne puisse pas intervenir en faisant des réglages fins au déploiement)