Implementation utilisateur des DAO
Bonjour à tous, D'après ce que j'ai vu dans le code de ToPIA-persistence, il n'y a pas de possibilité que l'utilisateur crée un DAOImpl personnalisé pour remplacer celui généré. En effet le DAOImpl est toujours généré donc incompatibilité si l'utilisateur en crée un nouveau et aucune prise en compte car l'interface (faux, voir plus loin) n'est pas mise à jour avec les nouvelles méthodes. A l'instar des Entités, il serait intéressant de pouvoir rajouté dans le modèle XMI la possibilité d'ajouter des méthodes sur les DAO et non sur les Entités. Pourquoi ? Tout simplement pour permettre l'ajout de méthode spécifique au DAO non généré (recherche complexe, autre traitement non pris en compte avec utilisation du SQL avec Hibernate (je sais plus le nom du langage) pour une requête complexe, ...). Je propose donc la prise en compte de ces méthodes en les signalant comme "static" au niveau des entités. La logique suit, une méthode static est bien général à l'ensemble des entités donc dans un DAO. Je viens de voir que les DAO n'ont pas le même modèle de génération que les entités à savoir : une interface, une classe abstraite, une classe implémentation mais une classe abstraite, une classe implémentation et une classe finale qui hérite de l'implémentation et est utilisé dans les Helper (donc par l'utilisateur). Pourquoi cette différence ? Du coup les changements serait a apporté normalement dans le DAOImplGenerator qui ne doit pas généré le DAOImpl si l'entité lié possède une méthode abstraite. Il serait intéressant pour globaliser cette notion de rajouter une méthode hasAbstractOperations dans ObjectModelClass de EUGene. Je m'égare peut-être, il y a peut-être déjà une autre possibilité d'étendre les DAO ? Sinon, qu'en pensez vous de pouvoir préciser des méthodes static dans les entités qui seront à implémenter par l'utilisateur dans les DAO (les méthodes ne seront pas static donc) ? J'espère avoir été clair et précis :p Florian
Le Fri, 22 May 2009 16:54:38 +0200, Florian DESBOIS <fdesbois@codelutin.com> a écrit :
Bonjour à tous,
D'après ce que j'ai vu dans le code de ToPIA-persistence, il n'y a pas de possibilité que l'utilisateur crée un DAOImpl personnalisé pour remplacer celui généré. En effet le DAOImpl est toujours généré donc incompatibilité si l'utilisateur en crée un nouveau et aucune prise en compte car l'interface (faux, voir plus loin) n'est pas mise à jour avec les nouvelles méthodes. A l'instar des Entités, il serait intéressant de pouvoir rajouté dans le modèle XMI la possibilité d'ajouter des méthodes sur les DAO et non sur les Entités. Pourquoi ? Tout simplement pour permettre l'ajout de méthode spécifique au DAO non généré (recherche complexe, autre traitement non pris en compte avec utilisation du SQL avec Hibernate (je sais plus le nom du langage) pour une requête complexe, ...).
Je propose donc la prise en compte de ces méthodes en les signalant comme "static" au niveau des entités. La logique suit, une méthode static est bien général à l'ensemble des entités donc dans un DAO.
Je viens de voir que les DAO n'ont pas le même modèle de génération que les entités à savoir : une interface, une classe abstraite, une classe implémentation mais une classe abstraite, une classe implémentation et une classe finale qui hérite de l'implémentation et est utilisé dans les Helper (donc par l'utilisateur). Pourquoi cette différence ?
Tu peux toujours écrire un helper qui étedns celui généré et des dao qui étendent ceux générés ? et donc dans ton helper écrire ce que tu veux ? pour récupérer ton DAO non générique...
Du coup les changements serait a apporté normalement dans le DAOImplGenerator qui ne doit pas généré le DAOImpl si l'entité lié possède une méthode abstraite. Il serait intéressant pour globaliser cette notion de rajouter une méthode hasAbstractOperations dans ObjectModelClass de EUGene.
Je m'égare peut-être, il y a peut-être déjà une autre possibilité d'étendre les DAO ? Sinon, qu'en pensez vous de pouvoir préciser des méthodes static dans les entités qui seront à implémenter par l'utilisateur dans les DAO (les méthodes ne seront pas static donc) ?
C'est pas du tout naturel à mon gout... Je suis plutôt contre car on indique quelque chose dans le modèle qui ne correspond pas à la réalité.
J'espère avoir été clair et précis :p
oui :)
Florian
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Fri, 22 May 2009 17:10:17 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Je m'égare peut-être, il y a peut-être déjà une autre possibilité d'étendre les DAO ? Sinon, qu'en pensez vous de pouvoir préciser des méthodes static dans les entités qui seront à implémenter par l'utilisateur dans les DAO (les méthodes ne seront pas static donc) ?
C'est pas du tout naturel à mon gout... Je suis plutôt contre car on indique quelque chose dans le modèle qui ne correspond pas à la réalité.
Moi, j'aime bien, si le static est choquant on peut le remplacer par un stereotype particulier (plus chiant durant la modelisation mais je suis d'accord ce serait plus coherent). Il faudrait aussi passer a spring pour faire tout cela, mais on va attendre un peu les premieres experiences guix et eugengo. -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
Benjamin POUSSIN a écrit :
Moi, j'aime bien, si le static est choquant on peut le remplacer par un stereotype particulier (plus chiant durant la modelisation mais je suis d'accord ce serait plus coherent).
Il faudrait aussi passer a spring pour faire tout cela, mais on va attendre un peu les premieres experiences guix et eugengo.
Salut, moi je n'aime pas du tout l'idée du static (ni du stéréotype). A choisir, je préfèrerais que dans le cas où on a besoin d'ajouter des méthodes dans le DAO, on modélise le DAO et on met une dépendance vers l'entité (ou chez pas quoi d'autre). Si un tel dao existe et qu'il a des méthodes, on les ajoute au dao généré, sinon on génère le dao normalement. Arno (et papi Ruchaud qui relit par dessus mon épaule... Et Yannick qui vient de nous rejoindre... Et Jaja qui vient de déclencher l'alarme dans le train...) -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
Le Thu, 28 May 2009 09:25:07 +0200, Arnaud Thimel <thimel@codelutin.com> a écrit :
Benjamin POUSSIN a écrit :
Moi, j'aime bien, si le static est choquant on peut le remplacer par un stereotype particulier (plus chiant durant la modelisation mais je suis d'accord ce serait plus coherent).
Il faudrait aussi passer a spring pour faire tout cela, mais on va attendre un peu les premieres experiences guix et eugengo.
Salut,
moi je n'aime pas du tout l'idée du static (ni du stéréotype).
je suis d'accord pour le coup du static qui pour moi ne veut rien dire, mais par contre je comprends pas ce qui te déranges dans l'utilisation d'un stéréotype ? cela me parrait pas trop mal ? Si tu peux un peu expliquer ce qui te dérange ? merci ;)
A choisir, je préfèrerais que dans le cas où on a besoin d'ajouter des méthodes dans le DAO, on modélise le DAO et on met une dépendance vers l'entité (ou chez pas quoi d'autre). Si un tel dao existe et qu'il a des méthodes, on les ajoute au dao généré, sinon on génère le dao normalement.
Arno (et papi Ruchaud qui relit par dessus mon épaule... Et Yannick qui vient de nous rejoindre... Et Jaja qui vient de déclencher l'alarme dans le train...)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Tony Chemit a écrit :
je suis d'accord pour le coup du static qui pour moi ne veut rien dire, mais par contre je comprends pas ce qui te déranges dans l'utilisation d'un stéréotype ? cela me parrait pas trop mal ? Si tu peux un peu expliquer ce qui te dérange ? merci ;)
Yep Ce qui me dérange c'est de mettre une méthode de DAO dans une entité. Dans le modèle on aurait une méthode "findByFirstname" sur une entité "Personne", je trouve ça crade. En fait j'me rend compte que c'est pas le stéréotype ou le static qui me déplait, mais de mettre sur une entité une méthode qui n'a rien à y faire. Suis-je clair ? :D Arno. -- Société Code Lutin http://www.codelutin.com tel : 02 40 50 29 28 fax : 09 59 92 29 28
On Thu, 28 May 2009 09:34:35 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Tony Chemit a écrit :
je suis d'accord pour le coup du static qui pour moi ne veut rien dire, mais par contre je comprends pas ce qui te déranges dans l'utilisation d'un stéréotype ? cela me parrait pas trop mal ? Si tu peux un peu expliquer ce qui te dérange ? merci ;)
Yep
Ce qui me dérange c'est de mettre une méthode de DAO dans une entité. Dans le modèle on aurait une méthode "findByFirstname" sur une entité "Personne", je trouve ça crade. En fait j'me rend compte que c'est pas le stéréotype ou le static qui me déplait, mais de mettre sur une entité une méthode qui n'a rien à y faire.
Si c ca qui te derange, c parce que tu ne vois pas le modele pour ce qu'il est :). Pour moi le modele n'est pas un diagramme de classe meme si ce qu'on utilise pour la modelisation, c plutot un diagramme qui permet d'exprimer ce que l'on souhaite a un niveau plus haut que le diagramme de classe (diagramme de classe == classe java existante) En B on dirait que tu vois ca a un niveau de raffinage plus fin que moi :). Si on faisait de la transformation de modele, moi j'ecrirais le 1er niveau alors que toi tu ecris directement le 2eme (apres transformation) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
On Thu, 28 May 2009 09:25:07 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
Benjamin POUSSIN a écrit :
Moi, j'aime bien, si le static est choquant on peut le remplacer par un stereotype particulier (plus chiant durant la modelisation mais je suis d'accord ce serait plus coherent).
Il faudrait aussi passer a spring pour faire tout cela, mais on va attendre un peu les premieres experiences guix et eugengo.
Salut,
moi je n'aime pas du tout l'idée du static (ni du stéréotype).
A choisir, je préfèrerais que dans le cas où on a besoin d'ajouter des méthodes dans le DAO, on modélise le DAO et on met une dépendance vers l'entité (ou chez pas quoi d'autre). Si un tel dao existe et qu'il a des méthodes, on les ajoute au dao généré, sinon on génère le dao normalement.
L'idee est sans doute la bonne, ajouter une classe si et seulement si on lui ajoute des methodes. Mais dans ce cas ce qui me chagrine un peu est qu'on se projete deja dans la solution technique et donc on se ferme un peu la porte a des evolution d'architecture. actuellement 1 Entity UML == 1 Pojo + 1 DAO + HBM et on aura alors 1 E + 1 DAO = 1 Pojo + 1 DAO + HBM Mais je devrais pouvoir survivre -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii
participants (4)
-
Arnaud Thimel -
Benjamin POUSSIN -
Florian DESBOIS -
Tony Chemit