Discussion :

[n!co]

Bonjour,

Je dois m'oqp de reengineering des méthodes de développement d'une boite avec entre le passage aux nouvelles technos java.
Tous cela dans le cadre de mon stage 8)

Pour faire qqs chose de nikel, je me suis mis à la recherche des conventions de nomage pour un développement J2EE, notament du coté des méthodes d'accès aux données.
Sur le site de sun je trouve tous, sauf ca ! Un petit coup de pouce me serait donc le bienvenue. D'autant que ca pourra servir à bcp demonde.

Merci d'avance

[zekey]

Qu'est ce qui n'est pas clair ?

[n!co]

Qui a dit que qqs chose n'était pas clair ?

C'est ma grande curiosité et mon perfectionnisme qui m'emporte et fait que je veux tjrs en savoir plus et de source fiable.

Par exemple, quand doit-on utiliser find au lieu de load et inversement, les requetes de modification, supression, etc ...

Je suis pointilleux je sais

[Alwin]

Je ne comprends pas trop, tu parles de conventions de nomage et ensuite de find, load, etc...

Les sources fiables sont chez sun...
La fiabilité en est relative mais, c'est la référence en la matière (ne pas oublier que le process JAVA n'est pas le même que le process J2EE).

Si tu parles des noms de méthodes, find et select sont standardisés dans la spécification EJB. Load ne l'est pas à ma connaissance maintenant, eu égard à mon grand age, je l'ai peut être zappé.

Les finder (méthodes findByXxxxx) doivent retourner des entité c'est à dire, des données d'un modèle gérés par ton composant (ce que j'appel un DOM pour Domain Object Model; cf. pattern évoqué par Rod Johnson).
Un sélecteur (méthodes selectXxxx) peu retourner un ensemble incomplet d'une entité comme des colonnes SQL.

La méthode que tu appel "load" doit être spécifiée dans la spec J2EE et plus précisément EJB (ce sont les seuls composants persistants de la spec) par la méthode findByPrimaryKey(Serializable key);
C'est la seule méthode qui permet de retourner une cardinalité 0..1 qui soit spécifiée dans J2EE.

Pour les méthodes store, create et remove, le nom est explicite.

Quand aux conventions de nomages JAVA de SUN, il n'y en as pas pour ce que l'on appel des DAO (Data Access Object).

Si tu as d'autres questions, n'hésite surtout pas

[dlemoing]

Petite précision, Domain Object Model est un pattern qui est aussi vieux que l'OOP. C'est l'idée qu'on peut modéliser une problematique sous forme d'objets (commande, compte bancaire, pret, ...) ayant un état (que l'on fait persister généralement) et un comportement (la logique métier) et qui agissent ensemble (voir le pattern Domain Model dans PoEAA)

Si tu veux avoir des exemples de nom de méthodes pour l'accès aux données, tu peux te tourner vers l'interface Session d'Hibernate 3 qui se rapproche de ce qui est attendu pour le PersistenceManager des EJB3.

[Alwin]

(oops, Martin Fowler et non Rod Johnson, bien vus Dlemoing)

[n!co]

C'est pas tout neuf, mais c'est en voyant un de tes messages Alwin que je me suis intéressé au sujet.

Je cite :

En normalisant les noms de tes méthodes, tu peu rendre générique les propagations aussi; par exemple, ta méthode getClientById normalisée en J2EE deviend findByPrimaryKey, getClientByCountry deviens findByCountry, etc...
Tu pourras ainsi placer l'attribut tranfactionnel sur la cléf "find*" de ton DAO.

C'est vrai quand cherchant sur le site de sun, je m'attendais a trouver une doc spécifique sur les conventions de nomage avec J2EE et bien que j'ai pensé au EJB (que je connais pas) j'ai pas trop étendu mes recherches.
En tout cas on peu dire que tu as bien répondu a ma question et je me fais une meilleur idée de comment nommer mes méthodes.

Pour le moment je me suis basé sur l'interface HibernateOperations du framework Spring, qui utilise cette même convention, je regarderais demain du coté de l'interface Session d'hibernate même.
Pour info, dans HibernateOperations, les methodes load permettent de retourner une instance persistente suivant son id, donc bien équivalent a une méthode findByPrimaryKey(...).

Tien vu que tu me le proposes, je vais poser une question sup, bien que je pourrais chercher moi même
Tu voulais dire quoi dans la citation ci-dessus ? rendre générique la propagation ? vers quoi ? (les EJB ?)


Un grand merci a tous les deux.

[Alwin]

rendre générique la propagation

C'est de moi ça ? où donc ?

[n!co]

voila le lien direct, ca aide
http://www.developpez.net/forums/vie...141168#2141168

[Alwin]

Ok, mais je parlais de Spring sur ce Thread et , en effet, normaliser les noms permet de généraliser certaines choses comme :
- Je ne suis pas techniquement transactionnel lors de mes lecture (excluse find/select)
par contre,
- je le suis pour le reste (* ou store/remove/delete)

Tout ceci n'est qu'un "aspect" des choses

[Alwin]

Pour revenir au nomage des méthodes; voici ce que dit la spécification EJB (Spec 2.1, chapitre 9.5.2 Finder Methods)

The name of each finder method starts
with the prefix “find”, such as findLargeAccounts. The arguments of a finder method are used
by the entity bean implementation to locate the requested entity objects.

The remote home interface includes the findByPrimaryKey(primaryKey) method, which
allows a client to locate an entity object using a primary key. The name of the method is always find-
ByPrimaryKey; it has a single argument that is the same type as the entity bean’s primary key type,
and its return type is the entity bean’s remote interface.

[n!co]

Et bien tous cela me semble très clair 8)

Merci de m'avoir consacré un petit peu de ton temps.