Hi Hammet, > -----Original Message----- > From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
> I think > persistence should be handle in a NOT transparent way. Doing persistence > in > a transparent way sounds like too much magic been added to an application > and problems can arise from that. > so we are on the same road! That was exactly the only thing I wanted to express. Sorry if I was not clear in that! So the question is, what we could / should do transparently and what we shouldn't. So my point of view - for programmers in an enterprise environment - is: 1) the programmer should work as much as possible with POJOs. He should be able just to use Collections, inheritance, all types etc. just as he is used to without persistence. 2) the programmer should not have to take care, whether he has updated an object and that this object should be updated to the database so. He shouldn't even need to add extra code for that. 3) the programmer shouldn't be touched with all kind of technical stuff like pooling, caching etc. So what should be explicit? Well I'm not perfectly sure about this. But 1) removing objects. This is something where persistent and transient objects differ in concept. 2) creating objects? Maybe this also could be transparent. Not sure 3) transactions? I'm not sure. We are talking of reusable components. Can we be sure, that one method of a component is always "transactional". Maybe we can solve that problem by having two methods with the same functionality but only one being "transactional". The second problem is, that we have to "connect" an object to a transaction, which is not a trivial task. What do you think? Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
