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 !