Discussion :

[anicaise]

Bonjour,

J'ai une question à la fois simple et compliquée. Je m'explique ...

J'utilise Ibatis comme framework de mapping relationnel dans une architecture en 5 couches dont une réservée au modèle de domaine.

J'ai besoin d'ajouter des méthodes de types Accesseurs qui vont "décorer" certains attributs de mon objet métier.

Je ne veux pas que ces méthodes se trouvent dans l'objet métier.

Comment faire ? Etendre mon décorateur de mon objet métier avec les méthodes "utilitaires" ? Si oui çà implique gérer des décorateurs dans ibatis et non plus des objets métiers purs ...

Pouvez vous m'éclairer ???

[gifffftane]

Mettre un accesseur dans un objet métier pour toute autre couche que la couche métier n'est pas du tout une décoration, c'est un scandale !

... cependant, qu'est-ce qui t'empêche de le faire ? Soit une décoration au sens classique, soit une classe fille... où est le problème ? Je pense que les considérations à la mode IOC, et Spring avec ses aspects pourraient t'aider ?

[anicaise]

Merci de ta réponse ...

Je suis bien d'accord avec toi sur le fait de ne pas rajouter d'accesseurs supplémentaires dans un objet métiers.

Effectivement j'optais plus pour un héritage ... une classe avec mes différents accesseurs qui étendrait de mon objet métier ...
La seule chose qui me dérange en fait dans ce principe c'est le fait de manipuler un tel objet dans toutes les couches ....

On est bien d'accord que dans la couche persistance, je vais utiliser l'objet qui étend de mon objet métier; le mapping objet se fera sur cet objet ...

Pour moi ces accesseurs seraient purement liés à la couche présentation, voir la couche services ... et n'ont rien à faire dans la couche de plus bas niveau ... Peut-être que je me trompe ...

Comment faire avec Spring ... ?

Merci !!

[gifffftane]

Que ce soit avec Spring comme avec le reste il n'y a pas de solution toute faite. La solution que tu choisiras comportera des forces et des faiblesses, et tu feras mieux la prochaine fois, c'est ainsi.

S'il y a des services à rendre dans la couche présentation qui ne sont pas du métier, alors il me semble que le mieux est de créer une classe de présentation qui a en attribut l'objet métier, et qui rend le service à partir de lui. L'héritage peut fonctionner, si c'est la couche présentation qui crée l'objet métier. Mais c'est souvent la couche DAO qui le crée, auquel cas tu es coincé.

Une bonne approche aussi est d'éviter de parler comme un informaticien : quels sont ces services qui sont de la couche présentation sans être de la couche métier, exprimés dans le langage de la couche Ah Ben Ça C'est Sûr ?

[anicaise]

Mais c'est souvent la couche DAO qui le crée, auquel cas tu es coincé.

Oui c'est tout à fait le cas. C'est Ibatis qui construit les objets métiers ... Pour conserver mon dialecte d'informaticien , les objets métiers représentent une couche transverse qui est le modèle de domaine. Les objets métiers sont accessibles depuis la couche Présentation, de Service ou les DAO.

Je vais donc définir des objets que j'appellerai des "beans decorator" qui ne contiendront que mes accesseurs dits "utilitaires". Ces beans decorator hériteront des objets métiers.
Ibatis fera le mapping directement sur ces beans decorator et ce sont ces objets qui seront manipulés dans toute l'application et non les objets métiers directement ...

Je trouve çà bizarre d'avoir des accesseurs supplémentaires dans la couche de persistence mais je ne vois pas comment faire autrement ...

Biensur je pourrai "decorer" mon objet métier direcetment dans ma couche présentation mais cela signifie travailler avec deux instances .... pas bon ...

Thanks !