Le Wed, 14 Mar 2012 18:59:56 +0100, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Wed, 14 Mar 2012 17:20:26 +0100 Brendan Le Ny <bleny@codelutin.com> wrote:
- Assumer qu'on fait du simili-DBdesigner et pas du DDD, dans ToPIA, on modélise une base de données relationnelles (pas trop de bidi etc...) et non un modèle métier. Donc ToPIA ne devrait pas m'imposer d'ajouter le stéréotype entity sur *toutes* les classes une par une que j'ajoute puisque de toute façon toutes les classes que j'ajoute sont des entités, y'a que ça dans mon modèle. Placer toutes ces classes dans un package entity (c'est déjà le cas, dans le pom on précise le package en question) devrait suffire.
Personnellement je suis pour la simplicité, mais je garderais tout de meme le stereotype entity sur les objets que l'on veut generer en entity. Par exemple on pourrait avoir certaine fois des interfaces entity et certaine fois non. Mais elle serait toujours dans le meme package.
Et surtout lorsque je regarde un modele et que je vois le stereotype entity je sais tout de suite le but de l'entity. (S'il n'est plus obligatoire, il va disparaitre, et la facilite de lecture avec :()
C'est assez "lourd" de devoir sur chaque entité mettre le stereotype <<entity>>. Je pense que dans un package "entity", on s'attend à avoir des entities. Par contre, tout le monde n'utilise pas un package entity. Ca m'est déjà arrivé, à Wiztivi par exemple, d'avoir des débats sur la façon d'organiser les packages : grosso modo, organisation technique ou fonctionnelles ? Dans le cas d'une orga orientée fonctionnelle, je pense qu'il devient alors nécessaire d'avoir le stéréotype sur les entities, DTOs, etc ... La solution pourrait peut etre de pouvoir appliquer le stéréotype sur un package, qui s'appliquerait à toutes les classes de ce package. Concernant les autres points, il y en a un peu beaucoup, et au fil des mails et réponses, ca va pas etre terrible pour répondre je trouve. Mais : - favorable à la dépréciation de topiaQuery (ou alors la simplifier autant que possible) - pour le passage en Runtime de TopiaException, je suis mitigé. Ne pas l'avoir en Runtime permet de rappeler qu'elle est là, et peut obliger à de la rigueur - la partie sérialisation demande peut etre de la reflexion sur la volonté/nécessité de sérialiser les entités. Si c'est pour en faire une vue précise, c'est le boulot d'un DTO pour moi. Pourquoi ne pas faire directement des tickets sur Topia, destinés à la V3, et d'y lancer les discussions ? Meme si j'estime plus reactif de répondre à un mail directement plutot que de voir un mail de commentaire, ouvrir son navigateur et la page associée, et répondre, il faut admettre quand dans les mails, c'est difficile de rebondir aisément à toutes les propositions/réactions. -- Yannick Martel