On Wed, 19 May 2010 18:03:52 +0200 Tony Chemit <chemit@codelutin.com> wrote:
Sachant cela, Cela te pose-t-il un problème ?
Pour moi c'est ok car si on veut un jour arriver à s'abstraire de ToPIA, il va bien falloir des getter autres que getTopiaId...
donc getId() c'est neutre et ça me va.
Si id est trop problématique, on pourrait pas utiliser technicalId ?
Oui getId() est tres problematique, c'est exactement ca, Donc autant utiliser topiaId car comme ca, ca fait de la pub en plus. Le cout/gain pour modifier topiaId en autre chose est beaucoup trop important pour le faire. Gain environs 0, cout environs enorme :( Donc on garde topiaId. Au pire du pire, j'accepterais peut-etre un getTechnicalId() en plus, mais du coup c redondant, deux facons de faire donc mauvaise facon. Si tu le veux vraiment, tu ajoutes dans tes classes impl (seulement de ton projet, pas dans les templates) un: getTechnicalId() { return getTopiaId();} Mais pour moi c'est vraiment affreux de faire ca :( Et pourquoi vouloir s'abstraire d'une abstraction ? Topia est justement la pour s'abstraire de la persistence du moment (DBManager, JDO, Hibernate, JPA). Car si on commence a vouloir s'abstraire d'une abstraction, je ne sais pas ou on va finir :(. (sans doute tres proche de l'usine a gaz :() Et si les projets etaient bien fait, ils n'utiliseraient pas le topiaId, mais la cle metier et donc jamais getTopiaId ne serait appele dans ton projet. (bon ok, la je pousse un peu :D, mais dans l'idee, ce n'est pas totalement faux) -- 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