On Fri, 26 Apr 2002 09:20, Jon Scott Stevens wrote: > on 4/25/02 3:37 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote: > > Hi, > > > > As a side note. I have heard good things about > > http://hibernate.sourceforge.net/ which is yet another persistence layer. > > Unlike all the other ones this does not force you to work within a > > particular model of development. ie It does not force you to regenerate > > sources (ie Torque), postcompile (ie Entity beans), or process it through > > bytecode augmenter (ie JDO). > > > > The persisted objects are simple java beans with setters and getters. The > > setters/getters need not be public but the system will only persist > > javabean properties. > > > > Anyways it looks like a very kool idea but I have not yet tried it. And > > before I jump into it I was wondering if anyone else has had a go? The > > main thing I guess I am interested in is the performance as none of its > > docs talk about how they cache instances of javabeans or when the beans > > are made stale etc. > > I like their quote in their FAQ... > > "And, at runtime, reflection isn't really as slow as people say." > > The reality is that reflection in pre-JDK 1.4 is terribly slow compared > with direct method calls.
1.3 reflection is a little better but the earlier stuff truly sucks ;) However the speed of reflection is such a minor part in persistence layer I could not see how it would effect performance. Especially given that you are going through jdbc possibly over IP to get to the underlying DataSource. What I guess the main performance characteristeric will be how they handle the instance cache, invalidation and so forth. Unfortunately I can't see any stuff on their websote regarding that. > FYI, Torque's re-generation of sources is really not that big of a deal. Depends on how often the schema changes ;) Or if you need to map it in different ways in different systems. However the main reason that I was looking at this was because the persistence layers suck in a distributed application. You end up creating dummy Value Objects for each persisted object or for each view which are 90% identical to actual persistent objects (minus the persistence framework specific parts). Sou you end up with something like following in torque MyData (The Biz Object) MyDataVO (The Value Object) MyDataPeer (The Peer) AbstractMyData (the abstract biz object) AbstractMyDataPeer (The abstract Peer) And the only one decoupled from the persistence framework is MyDataVO. In an ideal situation you would just have a single object "MyData" that is free from persistence framework and is nice and simple. (and basically a clone of MyDataVO). The rest of the stuff could be dynamically configured at runtime - including the mapping to physical datasource. Any system that did that and did not have all the rest of the cruft would be a sure winner IMHO. -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
